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

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

Я предполагаю, что это подпадает под несколько вопросов:

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

Мысли?

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

  • Уместно ли иметь поля, содержащие множественные и/или, возможно, неполные подмножества списка внешних ключей?

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

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

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

Ответ 5

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