Миграция БД: сохранить ограничения отношений?

Question

Риск быть названным дураком, мне интересно, что вы думаете о поддержании отношений отношений в БД MS SQL.

Я перевожу систему в среду .NET из ASP. Это приносит с собой бизнес-объекты и другие методы многоуровневого кодирования, которые работают для отделения базы данных от пользователя / API. Новое приложение имеет определенный API над Entity Framework DAL.

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

Есть ли какое-либо значение в сохранении ограничений отношений между таблицами?

Предположения:

• Код проверен
• В тех случаях, когда отношения важны, исполнение выполняется в рамках транзакции
• Доступ к БД осуществляется только через API, доступ третьих лиц не поддерживается.

Причины соблюдения ограничений:

• Обеспечивает структуру данных
• СОЕДИНЕНИЯ быстрее?
• Помощь в плане запросов?

Причины для удаления ограничений в новой версии .NET:

• Можно предположить, что логика API / BIZ будет управлять такими отношениями, как Parent / Child.
• Уменьшает возможность включения разделов БД в другие каталоги (система построена с использованием архитектуры Plug-in, большинство таблиц могут работать изолированно)
• Правильно ли я считаю, что SQL должен выполнять дополнительные проверки во время INSERT для ограничений, которые могут оказаться бесполезными, когда это управляет API над БД?

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

Большое спасибо,

Nathan

Answer 1

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

См. Также этот вопрос: Действительно ли необходимы внешние ключи при проектировании базы данных?

Answer 2

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

Внешние ключи также действуют как неформальный инструмент документирования для отношений в базе данных. Там, где FK присутствуют в базе данных, я могу спроектировать схему с помощью Visio (или любого другого инструмента, поддерживающего реверс-инжиниринг) и увидеть взаимосвязи. Удаление внешних ключей в базе данных во имя производительности является распространенным методом, используемым независимыми разработчиками программного обеспечения для запутывания своей схемы базы данных и получения большего дохода от поддержки.

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

Answer 3

Я не поддерживаю утверждение, что ограничения «индексируются автоматически». Только уникальные и первичные ключи. Внешние ключи этого не делают, хотя в большинстве случаев я бы рекомендовал иметь индекс для «потомка», соответствующий столбцам FK. Тем не менее, я бы по-прежнему рекомендовал FKeys, поскольку они

1. обеспечит целостность ваших данных (я слишком много кусал, потому что у BL были ошибки и я не смог выполнить работу).
2. Дайте оптимизатору больше информации о структуре ваших данных, что, в свою очередь, может привести к улучшению и ускорению выполнения планов.

Но, прежде всего, вы думали о том, чтобы хранить ваши данные в одной базе данных, но разделить их на несколько файловых групп? Вы могли бы достичь своей цели более гибким управлением дисковым пространством без лишних хлопот внешних ключей, охватывающих несколько БД