как следует поддерживать целостность данных в ситуации, когда отношение внешнего ключа может быть удалено

Допустим, у меня есть таблица PlantGroups. Они зависят от таблицы Plants и имеют внешний ключ PlantId. Каждая группа растений содержит только одно растение.

PlantGroups
==========
...data...
PlantId

Plants
======
PlantId

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

Кроме того, что, если другие данные в соответствующей записи PlantGroups (которая зависела от записи Plants, которая была запрошена для удаления) по-прежнему актуальны и заслуживают сохранения?


relational-database data-integrity
person Travis J    schedule 23.03.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

На начальном этапе, если PlantGroups может иметь более одного Plant, у вас должна быть дополнительная таблица с PlantGroupID и PlantID.

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

Что касается других ваших вопросов, вам следует изучить каскадные удаления. Кто-то еще может предоставить больше информации об этом.

person jheep    schedule 23.03.2012
comment
отредактированный вопрос, каждая группа растений может содержать только одно растение. - person Travis J; 24.03.2012
comment
Я намерен добавить логику, но мне любопытно, что скажут другие. Я знаю о каскадных удалениях, но, как указано в вопросе, я хотел бы избежать этого из-за все еще актуальных данных. - person Travis J; 24.03.2012
comment
Вы можете захотеть сохранить такую ​​информацию, как самый последний завод (или другую информацию, связанную с заводом) в группе растений, оставив текущий завод как нечто, что можно удалить, а затем обновить до нового завода. В качестве альтернативы вы можете сохранить статус растения, чтобы указать, что оно было удалено, чтобы другая логика могла выполнять более информированные действия. Например, чтобы он не отображался в результатах поиска как активный или чтобы поля не обновлялись до тех пор, пока у него не будет растения, которое не будет удалено. Все зависит от того, должна ли ваша система позволить этим отношениям быть более динамичными или статическими. - person jheep; 24.03.2012
comment
Мне нравится ваш комментарий, и я написал аналогичный ответ, как только вы, должно быть, его печатали. - person Travis J; 24.03.2012

arrow_upward
0
arrow_downward

Я собираюсь пойти с Option Other. Хотя это не определено ни в одном из руководств по целостности данных, которые я читал, включая оракулы (которые перечисляют только NULL, CASCADE, RESTRICT, NO ACTION, DEFAULT в качестве параметров), я собираюсь свернуть свое собственное.

Вот что произойдет, если кто-то еще не убедит меня в лучшем подходе.

PlantGroups
===========
... data  ...
PlantId

Plant
=====
PlantId
bool isActive

При удалении Plant для параметра isActive будет установлено значение false. Это приведет к включению большого количества дополнительной логики в управление базой данных, но позволит поверхностное удаление этих зависимых полей. Параметр каскадного удаления, возможно, будет последним вариантом для обработки устаревших данных, которым уже больше определенного количества лет.

В качестве альтернативы

У меня также может быть вторая база данных с той же схемой, что и первая, и содержащая удаленные данные.

person Travis J    schedule 23.03.2012