аффторКлюча нет. Есть только Forein Key ссылающийся на родительскую таблицу, и свойство ID товара.
В паре эти два поля дают уникальность записей.
С этим я могу согласиться, что этого достаточно.


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

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

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

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


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

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

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

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