Ограничения базы данных - сохранить или игнорировать?
Когда я учился в университете, они научили нас основам, основам и правилам базы данных, и одно из самых важных правил - это ограничения (первичный ключ, внешний ключ), и как сделать отношения 1-m, 1-1, mn,
Теперь, когда я перехожу в реальную деловую среду, они говорят мне: ты должен забыть все, чему тебя учили; нет ограничений, все эти отношения логичны, нет первичных ключей, нет внешних ключей, вы можете сделать свои ограничения с помощью кода.
Я не знаю, кто прав: что я узнал в своей академической жизни или что я буду изучать в моей новой реальной деловой жизни. Как вы думаете?
10 ответов
Я думаю, что ограничения помогают вам иметь чистые данные. Производительность иногда улучшается. В некоторых случаях производительность может зависеть от наличия ограничений. Тем не менее, ответ на этот вопрос не снимает ограничения. У вас есть то, что называется "денормализация", чтобы помочь вам справиться с проблемами производительности (при условии, что ваши запросы уже оптимизированы). В таких случаях вы всегда можете создать денормализованные сводные таблицы.
Парни, которые сказали вам "забыть то, что вы узнали", также сказали вам, что они забыли правила дорожного движения, которые они выучили на уроках вождения?
Если бы кто-нибудь сказал мне игнорировать ключи и ограничения в моих базах данных, я бы быстро проигнорировал их и занялся своими делами.
Первичные ключи, внешние ключи и ограничения существуют по определенной причине. Используй их. Они сделают вашу жизнь проще и вашу базу данных легче для понимания (и, зачастую, более производительным).
Чем дольше я работаю с базами данных, тем больше я ценю ограничения. В конечном итоге они экономят мне много времени. Только доверенные ограничения обеспечивают 100% достоверность данных.
Я написал главу об использовании ограничений и других способов обеспечения целостности данных, доступную для бесплатной загрузки здесь
Если вы думаете, что ограничения касаются только первичных ключей и внешних ключей, то на самом деле вас не научили основам с самого начала.
Я предлагаю вам взглянуть на "Введение в теорию реляционных баз данных" Хью Дарвена, которое свободно доступно в Интернете. И, по крайней мере, вы получаете истинное образование об "основах" от этого.
Ограничения базы данных - отличная идея, когда у вас есть пользователи, обращающиеся к базе данных, которые могут повредить ваши данные (то есть любой пользователь). Я стараюсь сохранить ограничения внешнего ключа, чтобы каждый, кто редактирует данные в моей базе данных, знал, что другие таблицы полагаются на данные в текущей таблице.
Я потратил много времени на исправление дерьмовых данных, полученных некомпетентными людьми, которые считают, что ограничения принадлежат коду приложения. Если база данных разработана без этих необходимых вещей, у нее будут плохие данные. Проведите быструю проверку любой системы, подобной этой, которая работает в течение нескольких лет, и вы найдете потерянные записи и недостающую необходимую информацию и т. Д.
Что ж, это, безусловно, правда, что существует очень мало истинных истин, и также верно, что многие коммерчески успешные продукты избегают декларированной ссылочной целостности (DRI).
С другой стороны, если вы заботитесь о данных в вашей базе данных, почти нет лучшего способа защитить целостность этих данных, чем с помощью DRI.
Если вы оставите все это на вершине кода, вы будете надеяться, что никто никогда не получит доступ к базе данных любым другим способом. Если они это сделают, ничто не остановит повреждение данных (осиротевшие строки, противоречивые и нелогичные данные).
То, что вы узнали, это не просто академические вещи. Но да, это как утопия Платона временами. Это идеальное состояние вашей базы данных, идеальный дизайн. Но этот идеальный дизайн не всегда возможен.
Ограничения должны быть как можно ближе к данным БД. Подумайте об этом таким образом. Что если вы написали свои ограничения в коде, а затем захотели перейти на другой язык / платформу, и в одном из ваших ограничений возникла ошибка? Это было бы катастрофично. Такие вещи, как PK, FK, ограничения и т. Д. Широко используются. Они используются уже более 30 лет. Таким образом, они не мусор, но в определенных сценариях они просто не поддаются управлению. Например, если вы Google, вы не можете просто полагаться на реляционную модель, которая дает ответы в миллисекундах.
Исходя из таких требований, как скорость и стабильность, мы иногда дублируем данные, не используем PK или не устанавливаем отношения и т. Д. Но только когда мы ищем что-то конкретное И когда мы знаем, что мы потеряем делая это таким образом.
В конце концов, реляционная модель - это всего лишь модель. Это способ представления вещей. Очень успешный способ, но это не находка, поэтому в некоторых случаях его нужно взломать.
Когда я был в классе, мы обращались к таблицам с необработанным SQL, и там было много необработанного SQL или его эквивалента. В этих случаях ограничения, как правило, хорошие.
Однако существуют системы, которые используют базы данных в качестве серверных частей, и к этим базам данных обращается только эта конкретная система программного обеспечения. В этом случае программное обеспечение должно отслеживать необходимые отношения и ограничения, а база данных служит избыточной проверкой, которая не обеспечивает хорошую обратную связь и снижает производительность.
Ограничения базы данных являются избыточными, поскольку подключенная система должна сама поддерживать эти ограничения. Обратная связь заключается в том, что определенное ограничение базы данных было нарушено. Если программа способна справляться с такой обратной связью, она может выполнять свои собственные проверки. Стоимость исполнения должна быть очевидной.
Ограничения могут быть полезны для систем разработки или тестирования, но когда система запускается в производство, все, что они могут сделать, - это аварийно завершить работу системы, если что-то пойдет не так, и обычно это именно то, чего вы не хотите делать в такой большой системе, как тот.
Первичные ключи важны. Вам нужен способ уникальной идентификации строк.
Но по моему опыту, если вы правильно инкапсулируете свой доступ к базе данных в классах (то есть, читаете / записываете объекты в / из БД), ограничения обычно не нужны. Да, я мог бы использовать их, если бы 50 разных приложений на 10 разных языках использовали одну и ту же базу данных. Но если бы это было одно приложение или общий набор приложений, совместно использующих базу исходного кода, я бы предпочел иметь всю логику манипулирования базой данных в одном месте, чтобы сделать приложение более удобным в обслуживании. То же самое относится и к хранимым процедурам, но у них есть дополнительная проблема переносимости между системами БД, если вы пишете код, предназначенный для обработки широкого спектра баз данных.