Sozonov,

нужен ли в таблице суррогатный ключ - знать никто кроме вас не может. Естественный ключ у вас тут напрашивается (car, part).

Sozonov,

да. Сделайте (car,part) первичным кластерным ключем и не мучьте животное.

spтут 2 определяющих фактора для создания суррогатного PK:

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

если есть хоть один из факторов - необходим суррогатный PK
Оба утверждения очень спорны. Ссылки вполне себе могут проходить и по естественному ключу, если он небольшой, а редактирование записей вовсе не означает изменения ПК. По сути, единственное очень и очень существенное пожелание к ПК - это то, что он не должен меняться, иначе возникает изрядное количество заморочек.

GoffmaniljyПо сути, единственное очень и очень существенное пожелание к ПК - это то, что он не должен меняться, иначе возникает изрядное количество заморочек.

Каких именно заморочек?
Просто я не раз сталкивался со сменой PK с естественного на суррогатный, особых проблем не припомню.
Я имею ввиду заморочки при работе с изменяющимся естественным ключем.

Goffmaniljy,

ну так что за заморочки то?
Необходимость каскадных изменений зависимых таблиц при изменении ПК. Проблемы при изменении ПК пользователем. Проблемы в триггерах при сопоставлении inserted-deleted. Вот навскидку.

Goffmanв триггерах доступно и новое и старое значение, да и в таких кросс-таблицах обычно триггеров не делают.
И что? Как вы узнаете, какая строка какой соответствует? И, во-первых, натуральные ПК бывают не только на кросс-таблицах, а во-вторых - триггеры часто используются даже на них для поддержания целостности.
Goffmanполучается, что проблемы могут быть, только когда на эту таблицу кто-то ссылается?
Проблемы возникают, когда вам нужно отследить изменения записи. Причем как раз проблемы со ссылками и пользовательскими изменениями решаются (ссылки автоматически изменяются движком сервера, а клиент вполне может сохранять старые значения ПК и обращаться к записи по ним), а вот с триггером - увы. Еще пример - журналирование изменений.

spiljyОба утверждения очень спорны. Ссылки вполне себе могут проходить и по естественному ключу, если он небольшой, а редактирование записей вовсе не означает изменения ПК. По сути, единственное очень и очень существенное пожелание к ПК - это то, что он не должен меняться, иначе возникает изрядное количество заморочек.

Конечно они могут быть спорны если все время изобретать велосипед, но данные факторы для создания PK выработаны из широкой практики. И понятное дело если вы мучаетесь с каждым объектом базы данных снова и снова - без фреймворков - то конечно можно при редактировании сущности и работать с составным ключом из 5 - 10 полей - никто этого не запретит! :))
Мучаются те, кто потом пытается оптимизировать базы, созданные теми самыми фреймворками. Вот, например, прелестная вещь - гуид, очень удобно - уникальность гарантирована (вроде бы), получать легче легкого даже на клиенте, самому ничего отслеживать не надо, напихал в каждую таблицу и радуешься. А всякие ДБА - идиоты, говорят про какую-то фрагментацию, раздувание индексов и прочую никому не нужную хрень.

GoffmaniljyИ что? Как вы узнаете, какая строка какой соответствует?
Запросто, помогут :new или :old
Несомненно, вот только они доступны только в триггерах FOR EACH ROW, а они есть далеко не во всех СУБД.
GoffmaniljyИ, во-первых, натуральные ПК бывают не только на кросс-таблицах,
Просто тема именно про кросс таблицы.
Вы меня спрашивали про возможные проблемы с естественным ПК. На данной конкретной теме с ним никаких проблем нет, о чем я уже давным-давно сказал .
Goffmaniljyа во-вторых - триггеры часто используются даже на них для поддержания целостности.
Насчет часто, это вы преувеличили, и опять же, какую проблему решит именно суррогатный PK в данном случае - не раскрыли.

Да ну? Знаете, что такое каскадное удаление и изменение? А знаете, что при наличии нескольких ВК могут вызникать множественные зависимости и прочее, и СУБД тупо не дает задать для них ON DELETE CASCADE, и приходится реализовывать эту функциональность триггерами? По поводу "какую проблему" смотрите выше.
GoffmaniljyЕще пример - журналирование изменений.
частный случай ссылочной целостности.
эээээ.... Какая связь между ведением журнала изменений, с указанием кто и когда изменил запись, и ссылочной целостностью?? А неизменяемый ПК здесь нужен именно для того, чтоб надежно отследить историю изменений конкретной записи, для чего ее нужно однозначно идентифицировать все время ее жизни.