Есть ли какой-то недостаток, если таблица имеет много (более 20) ограничений внешнего ключа?

Question

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

Что если я наконец получу число таких полей в диапазоне 20-30? Будет ли это как-то «медленными» табличными операциями или нет на самом деле?

ДОБАВЛЕНО: Ожидается, что в таблицах значений будет только несколько записей, обычно 5-10 или что-то в этом роде. База данных SQL Server 2008.

Answer 1

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

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

Возможно, вы захотите запустить свои собственные тесты и убедитесь сами.

Answer 2

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

Если вы выполните ОБНОВЛЕНИЕ нескольких столбцов, необходимо проверить только ограничения для этих столбцов, и большинство СУБД будут проверять только эти ограничения.

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Я имею дело со сторонним приложением, у которого есть основные таблицы с соответствующими «пользовательскими» таблицами, где мы можем настроить свои собственные поля. К сожалению, мы постоянно используем «настраиваемые» поля и редко можем справиться только с основной таблицей.