Отношения в SQL Server и оптимизация

Question

Я был разработчиком определенного проекта, разработанного под sql-сервером и .Net, они не используют физические отношения между своими таблицами, но используют логические "логические внешние ключи".

Я спросил их, по какой причине они это делают, они говорят: «Это более оптимально».

Что я действительно хочу знать, действительно ли это более оптимально или это просто миф?

Answer 1

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

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

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

Подробнее об этом: http://msdn.microsoft.com/en-us/library/ff647793.aspx

Answer 2

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

На производительность влияют то, как хранятся таблицы, какие индексы для них определены, а также хранится статистика (только некоторые из них).

Это плохое оправдание для отсутствия ссылочной целостности в базе данных (в частности, поскольку это может быть тривиально для тестирования).

Answer 3

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

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

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

Представьте, что у вас есть таблица для компаний, а затем еще одна таблица для сотрудников. Ваша таблица сотрудников, скорее всего, будет иметь столбец с названием companyId.

При запуске:

delete from Companies where companyId = 123;

Сервер базы данных должен убедиться, что в этой компании нет сотрудников. То же самое относится и к бегу:

 insert into Employees (companyId, name) values (123, 'John');

Сервер базы данных должен выполнить поиск в таблице компаний, чтобы убедиться, что companyId 123 существует.

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

Редактировать Как указал Мартин Смит, и я ушел, есть некоторые случаи, когда внешний ключ будет быстрее. Если в таблице есть внутреннее соединение с внешним ключом, а вторая таблица не ссылается ни на какие столбцы, запрос не должен попадать во вторую таблицу, поскольку он может доверять внешнему ключу.