Здравствуйте, Lexxpin, Вы писали:

L>Добрый день.
L>Если в базе MS SQL 2005 убрать всю ссылочную целостность,
L>то производительность повыситься или нет?

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

Добрый день.
Если в базе MS SQL 2005 убрать всю ссылочную целостность,
то производительность повыситься или нет?
Спасибо.

Здравствуйте, Lexxpin, Вы писали:

L>Добрый день.
L>Если в базе MS SQL 2005 убрать всю ссылочную целостность,
L>то производительность повыситься или нет?
L>Спасибо.

Повыситься, н онадежность упадет

Lexxpin пишет:

> Если в базе MS SQL 2005 убрать всю ссылочную целостность,
> то производительность повыситься или нет?

Повысится. Или не уменьшится.

Здравствуйте, Lexxpin, Вы писали:

L>Добрый день.
L>Если в базе MS SQL 2005 убрать всю ссылочную целостность,
L>то производительность повыситься или нет?
L>Спасибо.

Вроде должна немного повыситься, но точных цифр не знаю. По поводу аналогичной ситуации в Oracle — читал в одной из книг Тома Кайта, что производительность повышается на 10-15%.

Здравствуйте, Flying Dutchman, Вы писали:

FD>Здравствуйте, Lexxpin, Вы писали:

L>>Добрый день.
L>>Если в базе MS SQL 2005 убрать всю ссылочную целостность,
L>>то производительность повыситься или нет?
L>>Спасибо.

FD>Вроде должна немного повыситься, но точных цифр не знаю. По поводу аналогичной ситуации в Oracle — читал в одной из книг Тома Кайта, что производительность повышается на 10-15%.

Ага, "волосы более шелковистые на 60%".
Для некоторых операций вставки, некоторых операций обновления — возможно. Для операций выборки никак не повысится.

Flying Dutchman пишет:
> Вроде должна немного повыситься, но точных цифр не знаю. По поводу

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

Конкретные цифры сильно зависят от количества и качества связей.

Здравствуйте, _d_m_, Вы писали:

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

IB пишет:

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

Откуда информация ? Я лично про такое слышу впервые.

Здравствуйте, MasterZiv, Вы писали:

MZ>Откуда информация ?
От разработчиков. Да и вообще, достаточно известный факт — вот, например, как делает это DB2 (вторая ссылка в гугле) http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.admin.perf.doc/doc/c0055081.html
MSSQL умеет не хуже — искать пруфлинки лень.

MZ>Я лично про такое слышу впервые.
И что тут удивительного?

IB пишет:

> MZ>Я лично про такое слышу впервые.
> И что тут удивительного?

Действительно ничего удивительного, с DB2 я совсем не знаком.
Ну, а что у неё один из самых продвинутых оптимизаторов -- это известно.
Хотя я нашёл кое-что что и другие СУБД делают.
Но тем не менее, если DB2 всё это делает ( в статье этого НЕ СКАЗАНО на
прямую ) -- это очень здорово.

Здравствуйте, MasterZiv, Вы писали:

MZ>Действительно ничего удивительного, с DB2 я совсем не знаком.
А те, с которыми знаком, этого не умеют что ли?

MZ>Ну, а что у неё один из самых продвинутых оптимизаторов -- это известно.
Оптимизатор MSSQL-я сравнялся с оптимизатором DB2 по "продвинутости" в районе 2000-го сиквела. А уж учитывать констрейнты он умел еще в семерке.

MZ>Но тем не менее, если DB2 всё это делает ( в статье этого НЕ СКАЗАНО на
MZ>прямую )

These constraints provide semantic information that allows the DB2® optimizer to rewrite queries to eliminate joins, push aggregation down through joins, push FETCH FIRST n ROWS down through joins, remove unnecessary DISTINCT operations, and perform a number of other optimizations.

Куда тебе уже прямее-то?

Здравствуйте, MasterZiv, Вы писали:
MZ>Но тем не менее, если DB2 всё это делает ( в статье этого НЕ СКАЗАНО на
MZ>прямую ) -- это очень здорово.
Как это "не сказано"?

These constraints provide semantic information that allows the DB2® optimizer to rewrite queries to eliminate joins, push aggregation down through joins, push FETCH FIRST n ROWS down through joins, remove unnecessary DISTINCT operations, and perform a number of other optimizations

The following query could then avoid performing the join between CUSTOMER and DAILY_SALES, because no columns are retrieved from CUSTOMER, and every row from DAILY_SALES will find a match in CUSTOMER. The query optimizer will automatically remove the join.

Вот из прикольного про FK и оптимизацию в MS SQL:
http://msdn.microsoft.com/en-us/library/ms177416(SQL.90).aspx
Заметим, что

When the DATE_CORRELATION_OPTIMIZATION database option is set to ON, SQL Server maintains correlation statistics between any two tables in the database that have datetime columns and are linked by a one-column foreign key constraint.

Почему-то не могу найти других упоминаний про использование семантических оптимизаций. Но было бы крайне странно, если бы пацаны сделали учёт корреляции дат по FK (что даёт эффекты третьего порядка малости), и не сделали учёт наличия FK (что даёт эффект второго порядка).