Identity и естественный ключ

В книжке Джо Селко "стиль программирования Д. Селко на SQL" он яростно критикует identity в качестве первичного ключа (причем говоря, что identity основывается на физическом хранении данных, что вроде бред).Но вот скажите, является-ли преступлением использовать identity столбец просто для ссылки на строку? Например таблица Деталь:
create table (IDДетали int identity, IDИзделия int, Шифр varchar(<b>100</b>), Наименование varchar(<b>100</b>))
Первичным ключем тут является IDИзделия + Шифр, причем если IDИзделия развернуть в его естественный ключ, то получиться связка НазваниеЗаказа + НазваниеИзделия + Шифр.Теперь если все это дело перенести в таблицу с деревом изделия, то вместо
create table (IDСборки int, IDДетали int, Количество int)
получиться монстр из 7 столбцов вместо 3. Что плохого в использовании такого указателя, вместо полного ключа, который жрет место и только путает ? Ведь первичный ключ никуда не делся, он есть, просто для связки с другими таблицами используется более удобный указатель ...
6 ответов

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


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


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


Для этого много ума не надо.P.S.IMHO, трудолюбивый программист - это очень странно.
Плохо, что Джо Селко не упомянул, что для кластерного индекса количество задействованых полей должно быть минимальнымBOL->Using Clustered Indexes
It is important to define the clustered index key with as few columns as possible


если естественный ключ - числовой ничего плохого в этом нет.если строковый попробуйте сами сделать вывод:строковые данные требуют гораздо больше места для хранения.если связь двух таблиц по строке то строка должна быть в обеих таблицах.операции сравнения строк требуют на порядок больше ресурсов - процессорных на сравнение (числа сравниваются за такт, строки посимвольно)- канала доступа к памяти (объем строк на порядок больше)назначение первичного ключа - однозначная идентификация строки таблицы при обновлении.смотрим что легче обновить поле Ч где номер строки = 12345или обновить поле Ч где IDДетали = 12345 and IDИзделия='xyz' and Шифр = 'abc'нехочу козырять невежеством, незнаю кто такой джо, но мелькало несколько раз это имя в статьях, неплохие идеи, странное суждение к конкретному вопросу, может неблагоприятно вытянуто из контекста


Селко это такой товарисч, который призывает программировать так, чтобы продукт легко переносился с одной СУБД на другую. То есть серьезные проекты он либо не делал, либо тормозили они у него жутчайшим образом. Таким образом для его стиля вполне достаточно 7 версии SQL Server в самой дешевой редакции - никакие навороты использовать не рекомендуется (А вдруг захочется перенести все на Оракл?! А потом - на DB2? ;) )Уже одно его отношение к оппонентам говорит о том, что он даже и не пытался проанализировать плюсы и минусы других методов, а книга написана, чтобы оправдать собственную некомпетентность или нежелание осваивать что-то новое.