Цитата(LSD @ 15.11.2006, 13:02  ) | По поводу эффективности, не скажу за все СУБД, но в Oracle вот такой primary key:
код SQL
1:
constraint PK_tbl4 primary key (id1, id2, id3, id4)
будет использоваться только если идет запрос по первым полям, т.е.: id1 или id1, id2 или id1, id2, id3 или id1, id2, id3, id4. Если выборка идет по другой комбинации полей (например id2, id3), то индекс использоваться не будет, и будет full scan. |
Да, именно так. И именно поэтому я сразу указал порядок полей. И можно заметить, что в моих запросах в условии стоит первое поле первичного ключа.
| Цитата(LSD @ 15.11.2006, 13:02 ) | | В это топике обсуждается составные primary key, а не организация foreign key. Я спрашивал зачем нужно было включать поля id1, id2, id3 в primary key, а не зачем ты их добавил в таблицу tbl4 или сделал по ним foreign key. |
Хм. А кто начал спрашивать в десять вечера, какие foreign key у меня есть? 
Включаю я их в PK для по нескольким причинам:
1. Это набор полей, однозначно идентифицирующий запись. Можно заметить, я нигде не упоминал, что все они автоинкрементные. На мой взгляд, подобную иерархию на автоинкрементах и представить-то сложно  В реальности tbl2 у меня, к примеру - соединение многие-многие двух таблиц. Зачем мне там автоинкремент? Первичный ключ в этом случае автоматически получается конкатенацией ПК этих таблиц...
2. Для сохранения целостности: этим я явно показываю, какие записи могут быть в таблице. Разумеется, можно сделать, напрмиер в tbl4 один ключ id4 (если, подчеркиваю, это автоинкремент) и сделать ограничение уникальности (альтернативный ключ). Но это мне не надо: тогда индекс первичный ключа вообще в запросах участвовать не будет! Он не несет нужной информации. Только при выборке на клиент данной записи для редактирования, разве что (я не заржавею, написав для этого условие по 4 полям для составного ключа).
3. Для указания разработчику, с чем повязана эта таблица и как. Включение этих полей в ПК сразу подразумевает, что это именно подчиненная таблица, связь идентифицирующая, и вся работа с ней должна проходить с использованиемее предков. Плюс - перемещение записи между предками либо недопускается в реальности, либо чрезвычайно редкий сервис (я уже приводил пример, счет, состоящий из заголовка и содержимого. Нафиг содержимое перемещать? Или, например, это просто детализация записи мастера - тоже перемещать нет смысла). Конечно, разработчик всегда может посмотреть на схему данных, полная - на стене висит, два листа А0. И есть поблочная, листиков 30 А4... Как показывает прктика, уж лучше чтобы БД максимально подсказывала, что в ней есть.
4. Как показывает практика, выборки при схеме с составными ключами идут практически все по ним! Либо по первым полям, либо по всем. Немногие исключения - именно при унаследованной связи многие-многие, например, рассмотрим частично модифицированную схему:
| Код |
сreate table tbl3 (
id1 integer not null,
id2 integer not null,
id3 integer not null,
constraint PK_tbl3 primary key (id1, id2, id3),
constraint FK_tbl3_tbl2 foreign key (id1, id2)
references tbl2 (id1, id2)
on update cascade
on delete cascade,
constraint FK_tbl3_tblN foreign key (id3)
references tblN (id3)
on update cascade
);
create table tbl4 (
id1 integer not null,
id2 integer not null,
id3 integer not null,
id4 integer not null,
price numeric(18,2),
constraint PK_tbl4 primary key (id1, id2, id3, id4),
constraint FK_tbl4_tbl3 foreign key (id1, id2, id3)
references tbl3 (id1, id2, id3)
on update cascade
on delete cascade
);
create index idx_tbl4_tblN on tbl4 (id3, id4);
|
Обращаю внимание: tbl3 - фактически связь двух таблиц, tbl2 и tblN (не показана, первичный ключ id3) поэтому в tbl4 унаследованы поля из этих же таблиц. При возникновении задачи "выбрать все поля из tbl4 для данной записи в tblN" поиск по первичному ключу не пойдет, поэтому введен индекс, второе поле в котором для, эээ... у меня id4 не автоинкремент, и тоже участвует, как правило, в запросах .
|
