Что-то я не пойму твою мысль. Дай пример таблиц, ключей и констрайнов.

LSD, а чего там не понять?

ты делаешь:

tbl1(id1), tbl2(id2, id1), tbl3(id3, id2), tbl4(id4, id3)... etc

, а человеку удобнее:

tbl1(id1), tbl2(id2, id1), tbl3(id3, id2, id1), tbl4(id4, id3, id2, id1)... etc

хотя смысл подобных манипуляций от меня ускользает...   

Сорри, наоборот (первичные ключи):
tbl1(id1), tbl2(id1, id2), tbl3(id1, id2, id3), tbl4(id1, id2, id3, id4)...
В результате, при возникновении вопроса "мне нужны записи из tbl4, которые относятся к данной записи из tbl1 (то есть известно значение id1)", достаточно смотреть только на tbl4 

Т.е. в tbl4 - колонки (id1, id2, id3, id4) будут составным первичным ключем? А какие будут foreign key?

Так они очевидны - первичный ключ предка 
Например, у tbl4 это (id1, id2, id3), унаследованная часть первичного ключа.

А foreign key?

я о foreign key и говорю 
Вот например отрывок:

и тд.

Это сообщение отредактировал(а) Romkin - 14.11.2006, 23:49

Теперь возник вопрос: зачем надо было включать id1 и id2 в primary key?
Простой пользователь не должен синтетические ключи видеть вообще, а DBA не так уж и часто надо любоваться на PK, индекс по такому ключу менее эффективен. Вообщем я вижу только недостатки.

Я уже сказал: упрощаются запросы. Это как минимум. 
Например, если возникает задача выбрать записи из tbl4, которые принадлежат определенной записи из tbl1, в моем случае нужно сделать простой запрос к tbl4, id1 там есть и индексировано.
Если бы этих полей не было, пришлось бы делать join трех таблиц, это - чтение трех индексов.
Простой пользователь, разумеется, ключи не видит, а разработчик - у меня несколько людей смотрит структуру БД. И когда, смотря на таблицу, ты можешь сразу сказать, какое место в иерархии она занимает и с какими таблицами соединена, имхо, это большой плюс.
ТО, что индекс менее эффективен - а насколько? Во сколько раз индекс по 4 полям integer менее эффективен, чем по 1-2?

Каким образом включение id1, id2, id3 в primary key упрощает запросы?

Добавлено @ 11:12 

Это зависит от кучи факторов, и просто так сказать, что он менее эффективен в 2,36 раза нельзя.

Рассмотрим следующий скрипт (примерный, многие поля в таблицах опущены):

Задача:
Вывести из tbl1 Name и для каждого Name показать его сумму Price из таблицы tbl4.
Решение: 

Теперь рассмотрим другой скрипт, где ссылки - только на непосредственного предка:

Нужно то же самое. Можно, я не буду писать запрос с join всех этих таблиц?
У меня получается, что в первом варианте скорость выше, несмотря на то, что индекс используется частично. На практике, конечно, немного сложнее (у меня tbl2 - соединение многие-многие двух таблиц, там еще другие запросы), но запросы иногда нужны примерно такие.

Я не об этом.
В это топике обсуждается составные primary key, а не организация foreign key. Я спрашивал зачем нужно было включать поля id1, id2, id3 в primary key, а не зачем ты их добавил в таблицу tbl4 или сделал по ним foreign key.

По поводу эффективности, не скажу за все СУБД, но в Oracle вот такой primary key:

будет использоваться только если идет запрос по первым полям, т.е.: id1 или id1, id2 или id1, id2, id3 или id1, id2, id3, id4. Если выборка идет по другой комбинации полей (например id2, id3), то индекс использоваться не будет, и будет full scan.

Да, именно так. И именно поэтому я сразу указал порядок полей. И можно заметить, что в моих запросах в условии стоит первое поле первичного ключа.


Хм. А кто начал спрашивать в десять вечера, какие foreign key у меня есть?  
Включаю я их в PK для по нескольким причинам: 
1. Это набор полей, однозначно идентифицирующий запись. Можно заметить, я нигде не упоминал, что все они автоинкрементные. На мой взгляд, подобную иерархию на автоинкрементах и представить-то сложно  В реальности tbl2 у меня, к примеру - соединение многие-многие двух таблиц. Зачем мне там автоинкремент? Первичный ключ в этом случае автоматически получается конкатенацией ПК этих таблиц...
2. Для сохранения целостности: этим я явно показываю, какие записи могут быть в таблице. Разумеется, можно сделать, напрмиер в tbl4 один ключ id4 (если, подчеркиваю, это автоинкремент) и сделать ограничение уникальности (альтернативный ключ). Но это мне не надо: тогда индекс первичный ключа вообще в запросах участвовать не будет! Он не несет нужной информации. Только при выборке на клиент данной записи для редактирования, разве что (я не заржавею, написав для этого условие по 4 полям для составного ключа).
3. Для указания разработчику, с чем повязана эта таблица и как. Включение этих полей в ПК сразу подразумевает, что это именно подчиненная таблица, связь идентифицирующая, и вся работа с ней должна проходить с использованиемее предков. Плюс - перемещение записи между предками либо недопускается в реальности, либо чрезвычайно редкий сервис (я уже приводил пример, счет, состоящий из заголовка и содержимого. Нафиг содержимое перемещать? Или, например, это просто детализация записи мастера - тоже перемещать нет смысла). Конечно, разработчик всегда может посмотреть на схему данных, полная - на стене висит, два листа А0. И есть поблочная, листиков 30 А4... Как показывает прктика, уж лучше чтобы БД максимально подсказывала, что в ней есть.
4. Как показывает практика, выборки при схеме с составными ключами идут практически все по ним! Либо по первым полям, либо по всем. Немногие исключения - именно при унаследованной связи многие-многие, например, рассмотрим частично модифицированную схему:

Обращаю внимание: tbl3 - фактически связь двух таблиц, tbl2 и tblN (не показана, первичный ключ id3) поэтому в tbl4 унаследованы поля из этих же таблиц. При возникновении задачи "выбрать все поля из tbl4 для данной записи в tblN" поиск по первичному ключу не пойдет, поэтому введен индекс, второе поле в котором для, эээ... у меня id4 не автоинкремент, и тоже участвует, как правило, в запросах . 

В большинстве. Может, есть исключения, но я их пока не знаю...

Я уже понял, что это было опрометчиво 

Мне не нравится:

• UPDATE на первичный ключ в случае перемещений к другому родителю (если данные реплицируются, то будут проблемы)
• мне не нравится навешивание какой-то логики на первичный ключ
  

  Цитата(Romkin @  15.11.2006,  13:52 )

  Для указания разработчику, с чем повязана эта таблица и как. Включение этих полей в ПК сразу подразумевает, что это именно подчиненная таблица, связь идентифицирующая, и вся работа с ней должна проходить с использованиемее предков.

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