Должна ли среда разработки отключать внешние ключи?

Question

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

Мне было интересно, что люди думают об этой идее - при разработке вы оставляете включенными внешние ключи в своей среде разработки или отключаете их?

Answer 1

Я ВСЕГДА держу их включенными. Вы хотите убедиться, что ваш код не будет делать то, что нарушает правила FK. Если вы удалили их, ничто не помешает коду ввести неверные данные. Кроме того, мы будем использовать такие инструменты, как CodeSmith, чтобы помочь с некоторыми из наших частей автоматизации, а с CodeSmith он может автоматически генерировать процедуры запроса для нас, если у нас есть FK.

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Answer 10

У меня всегда включен FK, я понимаю предпосылку аргумента, что логика приложения должна обеспечивать ограничения данных, а не полагаться на сами ограничения БД, кроме этого, но я не думаю, что я был бы первым человеком, который имеет ранее в моей логике приложения пропущено каскадное ограничение, и база данных подобрала это для меня, я думаю, что это очень распространено, и, учитывая это в цикле разработки, это гораздо более приемлемо, чем в env производства!