необходим срочный ответ! 

при создании структуры БД возник небольшой спор по такой ситуации:

например, есть 2 таблицы, у каждой из которых есть первичный ключ
эти таблицы связаны между собой как многие-ко-многим
поэтому создается между ними промежуточная таблица, которая хранит в себе первичные ключи этих таблиц, т.е. они для нее являются foreign key

для промежуточной таблицы эти два форейн ки уже определяют ее первичный ключ
или все-таки для этой таблицы надо тоже выделять отдельный первичный ключ?

 я считаю, что так как таблица является связующей, то у нее 2 колонки, которые хранят форейн ки и вместе определяют первичный ключ

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

вот и вопрос: определять новый первичный ключ или нет? В промежуточной таблице никакая другая информация не хранится!

Это сообщение отредактировал(а) Scarlett - 21.12.2007, 19:44

скорее всего, говорящий человек ошибается в понятиях: путает теплое и мягкое.
первичный ключ - то, что однозначно идентифицирует запись.
зачастую, в таблице, хранящей связь многие-ко-многим сочетание значений полей-ссылок на другие таблицы уже уникально. потому это сочетание и может быть первичным ключом(в модели - точно будет, для использования СУБД тоже можно указать - будет составной естественный первичный ключ). Можно добавить дополнительно автоинкрементное поле, которое объявить первичным ключом таблицы. Это будет простой синтетический(искусственный) первичный ключ.
Слегка подытожу: есть составной(из нескольких полей) и простой(из одного поля) первичный ключ, а есть естественный(уникальность определяется логикой модели, точно так же, как ДНК абсолютно уникально безо всяких паспортных номеров - даже у клонов за счет мутации генотип будет отличен) и искусственный(автоинкрементное поле) первичный ключ.
Так вот: в настоящий момент(если сочетание значений в каждой записи таблицы уникально) у тебя - составной естественный первичный ключ. А тебе предлагают просто синтетический первичный ключ.
----
Совет: если у тебя связь(которая имеет форму "многая-ко-многим") может иметь дополнительные аттрибуты и связи(т.е. на связь между сущностями ссылаются другие связи), то лучше ввести в третью твою таблицу синтетический простой первичный ключ, что не усложнять запросы объединениями таблиц по двум-трем полям. Если связь аттрибутов/зависимостей не может имет в пределах модели, вполне можно обойтись только имеющимимся полями - не стОит без нужды плодить не используемые данные.

В основном поддерживаю skyboy, про искусственный и естественный все правильно, но споры эти идут давно, и у всех есть свои мнения на этот счет. От себя добавлю, что система должна иметь возможность масштабирования, и здесь
Накладные расходы: дополнительное поле первичный ключ + уникальный индекс по паре внешних ключей. Как видно накладные расходы небольшие, но зато если потребуется ввести новую функциональность для этой связи (например добавить временные интервалы), затраты будут гораздо меньше. В общем я за искусственный ключ в любом случае, IMHO.

PS: на www.ibase.ru есть статья  очень старая, но кое-что можно для себя извлечь. 

спасибо за полный ответ 

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

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

если вопрос решен, помечаем его решенным(кликаем по надписи "пометить вопрос решенным" справа вверху над первым сообщением в теме).

Я считаю что такой ключ не нужен, т.к. это ухудшает производительность, а плюсов не дает.

Синтетический ПК создавался для того, чтобы абстрагироваться от пользовательских данных. Например если у нас ПК образуется по полям ФИО, то изменение ФИО (например опечатались при вводе) потребует изменения всех записей ссылающихся на данную. А синтетический ПК не как не связан с пользовательскими данными, и не должен никогда изменяться. 
В данном случае ПК тоже не будет никак связан с пользовательскими данными, и проблем ЕК в нем нет.

 не совсем так.
Вот ключевая фраза:


Представим, что потребовалось хранить период жизни записи-связи.
Например, было:
нужно сделать:
прикиньте затраты на изменение, при наличии/отсутствии синтетического ключа

При таком раскладе конечно - да... 
Но:
1. Это экзотика, такие вещи приходится делать редко.
2. Перестроение базы операция не рядовая и выполняется тоже крайне редко.

Сплошь и рядом.

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

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

Тогда это уже отдельная сущность, связанная с двумя другими. А тут речь шла о том, что есть связь между двумя сущностями.

не совсем. есть же понятие в ER-диаграммах "relationship-entity"("связующая сущность" в моем переводе) для сущности, не имеющей воплощения в реальном мире, но имеющей в пределах модели дополнительные атрибуты/связи.
но это уже вопрос терминологии.

Так а я о чем! и неважно, есть у нее физический смысл или нет (см. пост skyboy). Ну привел я пример с физическим смыслом... хотите без него? пожалуйста, навскидку - номера телефонов фирмы и список сотрудников. И связующая таблица - по каким телефонам до каких сотрудников можно дозвониться.

я потому и решила пойти на уступки и создать первичный ключ
так как ситуация с примером, который привел Deniz, может случиться, а может и не быть

таким образом вопрос закрылся 

Не хотелось добавлять после
но...
Scarlett, не описав проблему и предметную область полностью (что это за связь) Вы и получили такие ответы.


Не знаю как у Вас, но это происходит достаточно часто.
PS: как правило такие связи характеризуются не только периодом жизни(который всегда должен быть для истории), но еще дополнительными атрибутами. И если на первый взгляд их не видно, то потом, когда заказчик захочет, будет, как говорил классик, .

Это сообщение отредактировал(а) Deniz - 25.12.2007, 10:00

Я про связь с реальным миром и не говорил. Я говорю про, что - это или отдельная сущность (пусть и связующая) или связь в чистом виде. Для связей в чистом виде собственный СК не нужен.