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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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

Ответ 10

Важны основные ключи. Вам нужен способ уникальных строк ID.

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