Перенос БД: сохраните ограничения на отношения?

Мне интересно, что вы думаете о сохранении ограничений отношений в базе данных MS SQL.

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

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

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

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

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

Причины сохранения ограничений:

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

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

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

constraints sql-server
person Program.X    schedule 29.04.2009    source источник
comment
Кстати, глупых вопросов не бывает, есть только глупые ответы. Так что не беспокойтесь о том, что вас назовут дураком, этого не произойдет (или, по крайней мере, не должно быть!). Со всей честностью; Я тоже задавал себе этот ограничительный вопрос.   -  person pyrocumulus    schedule 29.04.2009
comment
Действительно, вы правы. Боится гнева педанта! Спасибо также за ссылку, которая не попала в поиск - даже за отличный поиск AJAXy при вводе моего вопроса.   -  person Program.X    schedule 29.04.2009

Ответы (3)


arrow_upward
1
arrow_downward

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

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

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

person LeoPasta    schedule 29.04.2009
comment
Спасибо. Я немного изменил свой ответ. Хотя механизм db не может автоматически добавлять индекс для FK, эффект примерно тот же, потому что в обоих случаях планировщик использует информацию для своего планирования. - person pyrocumulus; 29.04.2009
comment
Хорошая идея для файловых групп. Я знал, что они существуют, но я не администратор баз данных, поэтому не обращал на них внимания. Пока хорошо выглядит для сохранения взаимосвязей и использования файловых групп. Спасибо. - person Program.X; 29.04.2009

arrow_upward
2
arrow_downward

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

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

person pyrocumulus    schedule 29.04.2009

arrow_upward
1
arrow_downward

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

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

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

person ConcernedOfTunbridgeWells    schedule 29.04.2009