Когда ссылочная целостность не является соответствующей?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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