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

Absolutely keep them enabled. The existence of foreign key constraints is actually very useful in development; not using the constraints can allow for lazy development; moreover, it can allow for some serious problems to creep into the code, that could cause some difficulties when moving to a production environment.

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

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

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

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

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

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

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

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

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

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

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

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

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

I'm going to say, let's remove the constraints.

Down with FKs!

and remove all the indices, all other constraints as well.

Just kidding. :)

Of course.. keep it as close to production as possible - scale down the size of the data and please please please SCRUB the data before you distribute it.