таблица многие-ко-многимВот нужно сделать таблицу, связывающую две другие в отношении многие-ко-многим, скажем People(PeopleID, ...) и Bank(BankID, ...)

Можно сделать так:
PeopleBank(PeopleID, BankID, primary clustered key (PeopleID, BankID)) + индекс (BankID, PeopleID)

а можно так:
PeopleBank(ID, PeopleID, BankID, primary clustered key (ID)) + 2 индекса, (PeopleID, BankID) и (BankID, PeopleID)

вот какой способ предпочтительнее?

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

Модератор: Тема перенесена из форума "Microsoft SQL Server".
Если бы Вы были знакомы с теорией баз данных, то знали бы, что "способы" происходят от использования, в данном случае, реляционной модели данных, в которой связи между типами сущностей не поддерживаются. Тем не менее, если строго следовать теории баз данных (то есть, учитывать, что у связей не может быть свойств, связи всегда бинарные и всегда двухсторонние), то оба Ваши способа не верны. Верным будет создавать две "таблицы" на каждую связь (причем, независимо от мощности связи). В Вашем примере, это выглядит в "реляционной системе" примерно так:

PeopleBank(PeopleID, BankID, primary clustered key (PeopleID, BankID))
BankPeople(BankID, PeopleID, primary clustered key (BankID, PeopleID))