Я слышала мнение, что декларативная ссылочная целостность помогает СУБД выполнять запросы быстрее. Меня интересует — как это происходит. Объявленный внешний ключ помогает больше, чем просто индекс по дочернему атрибуту? Если да, то каким образом. Нет ли каких нибудь материалов, где это объясняется?
Насколько-то это упоминается у Кайта, в главе про materialized views.
Грубо говоря, в общем случае для оптимизатора чем больше информации — тем лучше; хотя вопрос, сумеет ли он ей воспользоваться.
Скажем, индекс — он индекс и есть. Внешний ключ, кроме индекса, несет информацию о том, что в привязываемой таблице есть запись, на которую идет ссылка — соответственно (глупый пример, но ничего лучшего в голову не приходит) outer join окажется эквивалентным более быстрому inner join.
Само собой, стоит также помнить, что ограничения целостности требуют дополнительных ресурсов при изменении данных.
Здравствуйте, PCherkasova, Вы писали:
PC>Я слышала мнение, что декларативная ссылочная целостность помогает СУБД выполнять запросы быстрее. Меня интересует — как это происходит.
Возможно, имелось в виду преимущество констрейнтов (декларативная RI) перед триггерами/ХП (процедурная RI). Действительно, триггер, содержащий некую проверку, будет влиять на производительность DML сильнее, чем эквивалентный ему констрейнт. Это происходит потому, что констрейнт проверяется самим SQL engine, то есть на самом низком уровне, где доступны максимальные возможности для оптимизации.
Здравствуйте, PCherkasova, Вы писали:
PC>Я слышала мнение, что декларативная ссылочная целостность помогает СУБД выполнять запросы быстрее.
Сервер какой?
Здравствуйте, Softwarer, Вы писали:
S>Грубо говоря, в общем случае для оптимизатора чем больше информации — тем лучше; хотя вопрос, сумеет ли он ей воспользоваться.
Если быть более абстрактным, то вообще любые декларативные правила помогают оптимизатору. Почему? Да потому, что для cost-based оптимизатора основным вопросом является селективность предикатов. При отсутствии констреинтов оптимизатор вынужден полагаться на весьма шаткие предположения. Иногда он может использовать статистику (которая тоже может оказаться неверной). При этом check constraint позволяет иногда (в случае несовместимости предиката) сделать вывод о нулевой селективности, а unique constraint означает что field=const найдет не более одной записи. Foreign key constraint — фактически, единственный способ для оптимизатора получить хоть какой-то намек на объем результата join. Потому что отсутствие однотабличных констреинтов можно восполнить статистикой, а вот информации о корреляции данных в разных таблицах оптимизатор не хранит. Я наизусть не помню формулу для оценки размера inner join, но наличие foreign key очевидным образом увеличивает эту оценку. А это, в свою очередь, влияет на оптимальность плана.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
