Как определить, заслуживают ли отношения таблицы базы данных соблюдение ссылочной целостности?

Question

У меня есть приложение, в котором большинство таблиц базы данных тесно связаны друг с другом. В настоящее время я применяю ссылочную целостность с помощью внешних ключей, но мне интересно, действительно ли это лучший подход. Бизнес-пользователи могут удалять данные в основной таблице из интерфейса администратора, что означает необходимость каскадного удаления (или написания нескольких операторов удаления), но я не уверен, действительно ли я хочу удалить все эти другие данные в в то же время. Это может быть много данных, которые * могут * пригодиться позже (возможно, отчеты?). Однако данные во вторичных таблицах в основном бесполезны для самого приложения, если не существует связь с первичной таблицей.

Answer 1

Учитывая эту опцию, я всегда храню данные. А поскольку у вас уже есть внешние ключи, у вас есть встроенная защита от нарушений целостности.

Если ваши пользователи хотят «удалить» запись и, следовательно, скрыть ее от приложения, рассмотрите стратегию «виртуального удаления» - пометьте запись как неактивную, вместо физического удаления ее из базы данных.

Что касается реализации, в зависимости от вашей базы данных, добавьте все, что равно булевой / битовой логике для вашей таблицы. Всем строкам по умолчанию присваивается значение true / 1; «удаляет» помечается как ложное / 0.

Answer 2

Вы можете использовать внешние ключи и отношения для обеспечения ссылочной целостности без использования каскадного удаления. Я редко использую каскадное удаление, поскольку всегда находил , зачастую лучше иметь данные и управлять ими / архивировать их лучше, чем удалять .

Просто напишите свою собственную логику удаления, поддерживающую ваши собственные бизнес-правила.

Отлично работают и логические удаления , и я их широко использую.

Answer 3

Вы не хотите удалять некоторые данные - вы, скорее всего, в конечном итоге получите мошеннические данные, которые вы и понятия не имеете, где они принадлежали. Это либо все, либо ничего.

Мягкое удаление, т. Е. Наличие битового поля в каждой строке, которое определяет, является ли запись «удаленной» или нет, и это путь. Таким образом, вы просто проверяете, удалена ли запись == true в API, и скрываете ее из приложения.

Вы сохраняете данные, но никто не может получить их через приложение.

Answer 4

Никогда не делайте физическое удаление. Вы можете добавить флаг BOOL IsDeleted, чтобы указать, что запись удалена. Если вы хотите «удалить» запись, просто установите флажок True.

Answer 5

Я бы использовал логическое / мягкое удаление . В основном это означает добавление еще одного столбца (возможно, битового столбца Deleted) к рассматриваемой таблице, который пометит конкретную строку как удаленную.

При этом «удаленные» данные - это просто: удаленные. Таким образом, он не может быть логически использован в отчетах и ​​подобных вещах. Чтобы преодолеть это, я бы также ввел столбец Hidden, чтобы скрыть некоторые строки, сохраняя их логическое значение.

Answer 6

Я бы сказал, как правило, используйте ограничения внешнего ключа - это «защищает» ваш дизайн БД в долгосрочной перспективе, а также целостность данных. Ограничения также существуют для того, чтобы явно указать решение дизайнера.

Я видел ограничения, наложенные на очень большие базы данных - это было бы одной из причин не использовать их, если сравнивать производительность и существенные накладные расходы внешнего ключа.