Когда ссылочная целостность не подходит?

Question

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

Полагаю, это подразделяется на несколько подвопросов:

1. Когда ссылочная целостность не подходит?
2. Уместно ли иметь поля, содержащие несколько и / или, возможно, неполные подмножества списка внешнего ключа?
3. Как правило, это должно быть решение по проектированию структуры схемы или решение по проектированию интерфейса? (Или, возможно, ни то, ни другое)

Мысли

Answer 1

Когда ссылочная целостность не подходит?

Ссылочная целостность, если она обычно не используется в хранилищах данных, где данные являются копией транзакционной базы данных только для чтения.Другой пример, когда вам не нужен RI, - это когда вы хотите регистрировать информацию, которая включает идентификаторы строк;поддержание ссылочной целостности для таблицы журнала, доступной только для чтения, является пустой тратой накладных расходов базы данных.

Целесообразно ли иметь поля, содержащие несколько и / или, возможно, неполные подмножества списка внешнего ключа?

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

Как правило, это должно быть решение по проектированию структуры схемы или решение по проектированию интерфейса?(Или, возможно, ни то, ни другое)

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

Только мои мысли.

Answer 2

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

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

Под «правилами валидации» я имею в виду такие правила, как «товары в корзине> 0». Вы можете или не можете хотеть правила проверки. Но я думаю, что первичные / внешние ключи всегда важны (или вы могли бы позже найти, что хотели бы иметь их). Я думаю, что они необходимы, если вы хотите выполнить репликацию в какой-то момент.

Answer 3

1. Когда ссылочная целостность не подходит?

   Иногда, когда вы копируете лоты массовых записей или восстановление данные из какой-то резервной копии, это удобно временно отключить ограничения референтных Целостность.

2. Целесообразно ли иметь поля, содержащие несколько и / или, возможно, неполные подмножества списка внешнего ключа?

   Копирование данных таким способом идет против концепции нормализация. Есть преимущества и недостатки этого подход.

3. Как правило, это должно быть решение по проектированию структуры схемы или решение по проектированию интерфейса? (Или, возможно, ни то, ни другое)

   Я бы посчитал это схемой дизайна решение. Подумай о лучшем способе смоделировать вашу проблему в реляционной термины. Используйте базу данных так, как она был предназначен.

Answer 4

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

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

Answer 5

1. Никогда, хотя некоторые люди в сферах NoSQL, multi-value и oo-db не будут чувствовать себя по-другому. Не слушайте их, они неправы.
2. Да. Например, если транспортное средство однозначно идентифицируется как (lotid, vin), то lotid является внешним ключом таблицы лотов. Если вы хотите найти все изображения для партии, вы можете присоединить таблицу vehicle_pictures прямо к таблице лота, используя подмножество ключа vehicle_pictures (lotid in (lotid, vin)). Или я вас не понимаю?
3. Схема, интерфейс идет вторым. Если схема плохая, хороший интерфейс не является долгосрочной целью.