Сначала немного фона, чтобы убедиться, что мы на одной странице.
Похоже, у вас также есть таблицы Bar
с A
в качестве ключа и Baz
с B
в качестве ключа, где таблица Foo
поддерживает пересечение «многие ко многим» отношения между Bar
и Baz
, например:
Bar(A) <=> Foo(A,B) <=> Baz(B)
Если это правда, вам нужно спросить себя, как вы будете использовать отношения. Если вы начнете с Bar
чаще, а затем вам нужно будет найти связанные значения Baz
, тогда первичный (кластерный) ключ должен быть (A, B)
. Если вы начнете с Baz
чаще, а затем вам потребуется получить значения Bar
, тогда первичный ключ должен быть (B, A)
.
Для этого вопроса нам дана ситуация (A, B)
, и мы спросили, является ли дополнительная клавиша (B, A)
хорошей идеей. Поэтому мы должны предположить, что вы чаще начинаете с Bar
записи и вам необходимо знать связанные Baz
записи: Bar -> Foo -> Baz
, или в худшем случае это 50/50.
Теперь ответим на вопрос.
Дополнительный индекс (B, A)
(или даже просто (B) INCLUDES A
) может будет полезен, если вы также иногда начинаете с записи Baz
и вам необходимо знать связанные Bar
записей (Baz -> Foo -> Bar
) ... когда у вас есть запросы, проходящие через Foo
в обоих направлениях.
Но также важно помнить, что дополнительные индексы имеют затраты на хранение, память и обслуживание. Будет ли дополнительный индекс оказывать положительное влияние на ваше приложение, зависит от того, будете ли вы использовать этот вид поиска достаточно часто, чтобы преодолеть эти затраты. Стоит также упомянуть, что если таблица часто меняется, затраты будут выше, потому что теперь каждое изменение также должно обновлять оба индекса.