Много случаев, когда в таблице связи N:N нужны дополнительные поля с информацией (да пусть и просто комментарий) и смысла включать эти поля в PK нет никакого (как минимум по той простой причине, что они могут редактироваться).

Делать не суррогатные ПК в таблице связей N:N на мой взгляд скорее антипатерн, чем best practics. На проблемы с составмыми ключами нарывался, а вот достоинств (кроме экономии места под суррогатный ключ) лично я не вижу.

IMHO & AFAIK

произведение - персона (автор) - роль в данном произведении

Пусть БД фильмов, роли могут быть: продюсер, режиссер, звукооператор, композитор и так далее

Если у Вас все связи N:N вида

TABLE1_ID number
TABLE2_ID number

я Вам завидую ))). В тех системах, которые я вижу/видел, такой "классический" случай скорее редкость и исключение. В 90% таблиц-связей есть еще какая-то информация, часто, там ее даже __больше__, чем в "основных" таблицах

И какие колонки в составной ключ?
особенно если роль - текстовое поле, или и то и другое (и справочник и текстовое поле)

Не странность. Т.к. обычно может быть +100500 вариантов, все из которых занести в справочник не реально, да и не нужно

Ну и нафига это тащить в индекс?

Да и для связи N:N в любом случае нужно минимум два индекса, ID с одной стороны и ID с другой стороны, а вот ценность составного индекса мне не очень понятна.

===

дискуссия "суррогатный ключ" vs "составной индекс" стара как мир

Суррогатный ключ как минимум достаточно сильно упрощается API внутри приложения

note: разумеется сильно/не сильно понятие субективное


Он не плох.

Просто он не сильно и нужен (даже без связи с суррогатным ключем), если нет обязательного требования контроля уникальности в базе. Но так как обычно требования на validation сильно сложнее, чем просто уникальность, то в большинстве случаев и для validation он не сильно поможет AFAIK

22167727


В 90% случаев, это не настолько большая проблемма по сравнению с тем, что система не дает ввести Стэнли Кубрик дважды в тех случаях, когда это требуется )))
/он и продюсер и режиссер/


Данная сущность в системе Oracle e-Business Suite выглядит примерно так. На самом деле FND_USER_RESP_GROUPS это view, на деле там все хуже ))). Но понятно, что user_id и role_id (resonsibility_id) совершенно спокойно (в OeBS) могут повторятся и это хорошо!

Была потребность в Oracle CC&B заводить для организации не один контактный телефон, а несколько ))) Поскольку Oracle CC&B проектировал архитектор с популярной сейчас ориентацией, там был уникальный составной ключ "организация" + "тип контакта" (телефон, e-mail, fax) и ввести два телефона или два e-mail'а было нельзя. Заводить в справочник "тип контакта" телефон1, телефон2...телефон999 и email1, email2...email999 посчитали дичью и решили пилить )))

На удивление, обошлось малой кровью, даже несмотря на то, что во всех процедурах (исходных кодов которых не было) системе передавался составкой ID просто в виде параметров по отдельности. Т.е., если делать "по хорошему", то нужно было бы менять описание/декларации 100500 процедур черт знает в каких местах системы. К счастью это не потребовалось, т.к. хоть параметры внутри системы и прокидывались, к отдельным строчкам таблицы обращение по "полному" primary key никогда не происходило. Весь блок (аккордеон) всегда считывался/записывался целиком.

Но встретили один "нежданчик". Hibernate потребовал, что бы все поля составного примари кей шли последовательно и в заданном порядке, а alter table ... add добавил колонку в конец. Долго искали, в чем же проблема (т.к. делало вид, что работало, но "не все функции выполняло"), потом поняли, что проблема в порядке полей в таблице - пришлось дропать таблицу и создавать поля в нужном порядке

1. для меня это не очевидно
2. у меня личная непереносимость использования date в качестве (или наподобие) id
особенно с учетом Oracle date (дата + время) и моей веры в профессионализм себя и моих коллег, что они запросто могут запихать повторы в СУБД, просто прибавив к "уникальной" дате по одной секунде )))

На order_lines (OeBS аналог Вашего order_details) - редко кто когда ссылаться будет и тяжяло даже такой сцераий выдумать ?

Резервирование на складе, отгрузка, последующие строки счет-фактура - все будет ссылаться как раз на order_lines

IMHO & AFAIK
привожу примеры тех. систем, которые видел