Какие преимущества дают ограничения базе данных?

Question

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

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

Мысли?

Answer 1

«просто» целостность данных?Ты так говоришь, как будто это мелочь.Во всех приложениях это критично.Так что да, он это обеспечивает, и это огромное преимущество.

Answer 2

Целостность данных — это то, что они предлагают.Во всяком случае, у них есть цена производительности (по крайней мере, очень незначительная).

Answer 3

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

Answer 4

Следующее, если вы изначально правильно поняли ограничение:

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

Answer 5

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

С практической точки зрения, обычно проще определить внешний ключ и позволить механизму БД убедиться, что отношение действительно.Другие варианты:

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

Answer 6

Данные — это актив.Во многих учебниках об этом говорится.

Но на самом деле это неправильно.Скорее следует сказать: «Правильные данные — это актив, неправильные данные — это пассив».

А ограничения базы данных дают вам наилучшую гарантию корректности данных.

Answer 7

В некоторых СУБД (например.Oracle) ограничения на самом деле могут улучшать производительность некоторых запросов, поскольку оптимизатор может использовать ограничения для получения знаний о структуре данных.Некоторые примеры см. эта статья в журнале Oracle.

Answer 8

Я бы сказал, что все необходимые ограничения должны быть в базе данных.Ограничения внешнего ключа предотвращают непригодность данных.Их не очень приятно иметь — они необходимы, если только вам не нужна бесполезная база данных.Внешние ключи могут снизить производительность удалений и обновлений, но это нормально.Лучше сделать удаление чуть дольше (или сказать приложению не удалять этого человека, так как у него есть заказы в системе) или удалить пользователя, но не его данные?Отсутствие внешних ключей может вызвать неожиданные и зачастую серьезные проблемы при запросе данных.Например, отчеты о затратах могут зависеть от того, что все таблицы имеют связанные данные, и поэтому могут не отображать важные данные, поскольку одной или нескольким таблицам не к чему присоединиться.

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

Вы не упоминаете другие ограничения, но вам следует это сделать.Любое бизнес-правило, которое всегда должно применяться ко всем данным в таблице, должно всегда применяться в базе данных через тип данных (например, тип данных времени, который не принимает «31 февраля 2009 года» в качестве допустимой даты), ограничение (скажем, тот, который не позволяет полю иметь значение больше 100) или через триггер — логика настолько сложна, что ее невозможно обработать с помощью обычного ограничения.(Триггеры сложно писать, если вы не знаете, что делаете, поэтому, если у вас такая сложная логика, в вашей команде, надеюсь, будет профессионал по базам данных.) Порядок важен.Типы данных являются первым выбором, за ними следуют ограничения, а затем триггеры в качестве последнего выбора.

Answer 9

Упрощенный код приложения

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

get department number for employee  # it's good coz of constraints
do something with department number

против.

get department number for employee
if department number is empty
    ...
else if department number not in list of good department numbers
    ....
else
    do something with department number

Конечно, люди, которые игнорируют ограничения, вероятно, в любом случае не прикладывают много усилий к проверке кода...:-/

Да, и если ограничения данных изменятся, это проблема конфигурации базы данных, а не проблема изменения кода.

Answer 10

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

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

Answer 11

«Да, и если ограничения данных изменятся, это проблема конфигурации базы данных, а не проблема изменения кода».

Если только это не ограничение, которое исчезает из дизайна.В этом случае определенно ЕСТЬ влияние на код, потому что мог быть написан некоторый код, зависящий от присутствия этого удаленного ограничения.

Это всегда следует учитывать при «ослаблении» или «удалении» любого заявленного ограничения.

В остальном вы, конечно, полностью правы.