Ограничения базы данных - сохранить или игнорировать? - PullRequest
19 голосов
/ 13 сентября 2010

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

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

Я не знаю, кто прав: что я узнал в своей академической жизни или чтоЯ буду учиться в моей новой реальной деловой жизни.Что ты думаешь?

Ответы [ 10 ]

29 голосов
/ 13 сентября 2010

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

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

12 голосов
/ 13 сентября 2010

Чем дольше я работаю с базами данных, тем больше я ценю ограничения. В конечном итоге они экономят мне много времени. Только надежные ограничения обеспечивают 100% достоверность данных.

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

11 голосов
/ 13 сентября 2010

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

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

6 голосов
/ 13 сентября 2010

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

Ребята, которые сказали вам «забыть то, что вы узнали», также говорили вам, что они забыли правила дорожного движения, которые они изучили на уроках вождения?

5 голосов
/ 13 сентября 2010

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

4 голосов
/ 13 сентября 2010

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

4 голосов
/ 13 сентября 2010

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

Ограничения должны быть как можно ближе к данным БД. Подумайте об этом таким образом. Что если вы написали свои ограничения в коде, а затем захотели перейти на другой язык / платформу, и в одном из ваших ограничений возникла ошибка? Это было бы катастрофично. Такие вещи, как PK, FK, ограничения и т. Д. Широко используются. Они используются уже более 30 лет. Таким образом, они не мусор, но в определенных сценариях они просто не поддаются управлению. Например, если вы Google, вы не можете просто полагаться на реляционную модель, которая дает ответы в миллисекундах.

Таким образом, исходя из таких требований, как скорость и стабильность, мы иногда дублируем данные, не используем PK, не устанавливаем отношения и т. Д. Но только когда ищем что-то конкретное AND когда мы знаем, что мы потеряем, делая это таким образом.

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

4 голосов
/ 13 сентября 2010

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

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

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

0 голосов
/ 13 сентября 2010

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

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

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

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

0 голосов
/ 13 сентября 2010

Первичные ключи важны. Вам нужен способ уникальной идентификации строк.

Но, по моему опыту, если вы правильно инкапсулируете свой доступ к базе данных в классах (то есть, читаете / записываете объекты в / из БД), ограничения обычно не нужны. Да, я мог бы использовать их, если бы 50 разных приложений на 10 разных языках использовали одну и ту же базу данных. Но если бы это было одно приложение или общий набор приложений, использующих базу исходного кода, я бы предпочел все логику манипулирования базой данных в одном месте, чтобы сделать приложение более удобным в обслуживании. То же самое относится и к хранимым процедурам, но у них есть дополнительная проблема переносимости между системами баз данных, если вы пишете код, предназначенный для обработки широкого спектра баз данных.

...