У меня есть приложение, в котором большинство таблиц базы данных имеют прочное отношение к другой таблице. В настоящее время я применяю ссылочную целостность с внешними ключами, но мне интересно, действительно ли это лучший подход. Данные в первичной таблице могут быть удалены из интерфейса администратора бизнес-пользователями, что означает необходимость выполнять каскадное удаление (или запись нескольких инструкций удаления), но я не уверен, действительно ли я хочу удалить все эти другие данные в в то же время. Может быть много данных, которые могут быть полезны позднее (возможно, сообщение?). Тем не менее, данные во вторичных таблицах в основном бесполезны для самого приложения, если отношения не существуют с первичной таблицей.Как вы определяете, подходит ли отношение таблицы базы данных к принудительной ссылочной целостности?
ответ
Учитывая этот вариант, я всегда храню данные. И поскольку у вас уже есть внешние ключи, у вас есть встроенная защита от нарушений целостности.
Если ваши пользователи хотят «удалить» запись, поэтому скрывая ее от приложения, рассмотрите стратегию «виртуального удаления» - отметьте запись как неактивную, вместо физического удаления ее из базы данных.
Что касается реализации, в зависимости от вашего db, добавьте все, что соответствует логической/битовой логике для вашей таблицы. Каждой строке присваивается значение true/1 по умолчанию; «deletees» отмечены как false/0.
Вы можете использовать внешние ключи и отношения для обеспечения ссылочной целостности без использования каскадных удалений. Я редко использую каскадные удаления, поскольку я всегда находил , часто бывает лучше иметь данные и управлять им/архивировать, а не удалять его.
Просто напишите свою собственную логику удаления, чтобы поддерживать свои собственные бизнес-правила.
Ложные удаленные операции отлично работают и я использую их широко.
Я бы сказал, как правило, использовать ограничения внешнего ключа, как правило, - это «защищает» ваш проект БД на долгосрочную перспективу, а также целостность данных. Существуют также ограничения, позволяющие явно сформулировать конструкторское решение.
Я видел ограничения, связанные с чрезвычайно большими базами данных - это была бы одна из причин не использовать их, если бы вы сравнили производительность, и накладные расходы значительного внешнего ключа.
Я бы использовал логический/мягкий удалить. Это в основном означает добавление еще одного столбца (возможно, столбца бит Deleted) в соответствующую таблицу, которая будет отмечать определенную строку как удаленную.
Это, как говорится, «удаленные» данные - это просто: удаленные. Таким образом, он не может быть логически использован в отчетности и подобных материалах. Чтобы преодолеть это, я бы также представил столбец Hidden, чтобы скрыть некоторые строки, сохраняющие их логический смысл.
Вы не хотите удалять некоторые данные - вы, скорее всего, закончите с данными изгоев, которые вы не знаете, где это было в первую очередь. Это либо все, либо ничего.
Мягкое удаление, то есть наличие поля бит в каждой строке, которая определяет, является ли запись «удаленной» или нет, является способом перехода. Таким образом, вы просто проверяете, удалена ли запись == true в API, и скройте ее из приложения.
Вы сохраняете данные, но никто не может получить их через приложение.
Никогда не делайте физических удалений. Вы можете добавить флаг BOOL IsDeleted, чтобы указать, что запись удалена. Если вы хотите «Удалить» запись, просто установите флаг «Истина».
+1. Я также избегаю Cascade Deletes. –