MasterZiv
> Т.е., возиможно, в вашем случае следует оба ключа отъюзать. У вас нет показаний
> к ID эту таблу из-за отсутсвия у нее дочерних, а не наличия других уникальных.
> Но ради единообразия стиля. Это вседа содержит надежду на возможное упрощение
> как на этапе разработки и сопровождения
> Например, в приложении в каких-то ситуациях запомнить запись по такому суррогату
> проще, поскольку уже многократно применялось. Ить он не меняется, а остальные то
> могли измениться в транзакции: поменяли порядок или отнесли к дугому товару.
> ID таблы, то врядли поменяется када либо.


Про деда -- очень хорошо! Но вы все тут путаете свойства PK и суррогатного
PK. Ну и доводы типа "ради единообразия стиля" -- как-то ненаучно выглядит.

Что имеено перепутано в свойствах? Ключ - уникальность, Суррогатный - значение ниче не значит в предметной области. Его польза в некоторых СУБД в связи с предположительной неизменностью. В частности для связи: снижение рисков изменений в дочерних таблицах.
Это имелось в виду.
Термин РК - старался не упоминать вообще.
Единнобразие стиля имеет не научное значенние а стилевое. Если в одной табле суррогат для записи , в другой естесвенный ключ для сущности, в третьей суррогаты от других табл (например, табла для связи многие ко многим), то стиль работы с ними разный. Это может усложнить разработку и сопровождение.

Пример, привел пользой от неизменности в проге. В проге что-то делают со значениями записей. Запомнили их суррогаты, если он есть. И например, поменяли значение остальных ключей. Но вседа записи нашли в этом коде и не перепутали: суррогат, то никому не нужен менять его, скорее всего. А если его нет, то несколько сложнее искать, ить все остальное поменяли - код может быть посложнее.

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