Перенос базы данных: сохранить ограничения отношений?

Question

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

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

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

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

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

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

Причины, чтобы иметь ограничения:

• Применяет структура данных
• JOIN и быстрее?
• Помощь в плане запроса?

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

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

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

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

Натан

Answer 1

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

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

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

Answer 2

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

Смотрите также вопрос: Are foreign keys really necessary in a database design?

Answer 3

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

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

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