Рекомендация: следует ли использовать FK на БД с помощью nHibernate / FluentNhibernate?

Question

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

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

Спасибо

Answer 1

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

Answer 2

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

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

Совершенно возможно объединить 2 мира (управляемая доменом и реляционная база данных) с NHibernate. Удостоверьтесь, что эти две области сосредотачиваются на том, в чем они лучше всего. Кроме того, база данных лучше всего хранит данные и следит за тем, чтобы данные оставались действительными / целочисленными.

Answer 3

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

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

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

Answer 4

Позволить Fluent / NH создавать вашу базу данных во время разработки - это хорошо, но когда она перейдет в рабочий режим, вам действительно следует проверить все внешние ключи, индексы и т. Д. И т. Д., А затем вносить изменения в сценарии только после.