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

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

например, есть 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

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

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

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

Scarlett, вообще-то архитектура многие-ко-многим не предусматривает никаких промежуточных таблиц.
Не следует этого делать, в такой таблице просто нет надобности.

Было бы очень неплохо увидеть структуру таблиц.

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

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

Что-то не понял... как это сделать без денормализации?

Для этого есть вторичные ключи ....

вот-вот...
и я о том же 

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

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

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

не вижу смысла спорить ....
чуть позже выложу статью, как правильно организовать связь многие-ко-многим, не теорию ВАЗов, а реальную практику ...

Это сообщение отредактировал(а) ZMaximI - 26.12.2007, 14:33

Ждем... тут выложишь, на форуме? 

Ждем с нетерпением. Очень интересно будет почитать.