Urri Вот у нас есть таблица персон с суррогатным ключом. И сегодня мы видим, что под записью с ID = 1234 скрывается Петров, паспорт 98 76 543210.
Приходим на работу завтра - и что видим: те документы, которые оформлял Петров теперь вроде как оформлял Васечкин, паспорт 67 89 452301! Объяснение оператора: "Ну и что: раз атрибуты можно менять, мы их и поменяли. А что, нельзя было? 8-[ ]
Это я к тому, что без дополнительных мероприятий СК не могут обеспечить целостность во времени. А ЕК - могут.
Бред. Введите в систему клиента, паспорта которого вы не знаете. Или клиента со справкой об освобождении и т.п. Бред.
Про смену паспортов говорилось. При этом _если_ в сиситеме на ЕСТЕСТВЕННЫХ ключах с КАСКАДОМ (ес-но, а как же поддерживать исправления при ошибках опператора?), оператор отредактирует полностью Васькина на Пупкина, то и все вхождения (в силу каскадов) поменяются на Пупкина. Или вторичных ключей не вводить? Или каскды не использовать? (отдельные процедуры на правку ошибочных значений ключей писать?) Прямо какой-то сивый бред. Если вам надо запретить изменение некоторых "естественно-ключевых" полей, т.е. "запретить" смену "физ сущности", но оставить лазейки для правки ошибок первоначального ввода - то делается это (в силу необходимости лазеек) именно что на уровне более гибком, чем пк - т.е. или (в конце концов) уровне приложения (или хп-шек).

Есть правда и способ с полным хранением исторических "представлений" (вообще без апдейтов записей, и сохранением всех ранее введенных (хотя бы в архиве)) сущностей (записей). В нем явно отслеживается, кто из операторов и в какой момент подменил "физ сущность" комплекта исторически связанных представлений. Но это затратно.



ОФТОП: И вообще "ЕК" и "СК" - "одинаково" суррогатны. Т.к. никаких "сущностей" и "атрибутов" в природе (отдельно от голов) не существует. Они в ней появляются благодаря головам. То что к примеру дебила зовут Федя, "Федя" может и не знать вовсе. Более того, когда он помрет, сущности "Федя" в природе не будет. А знать о ней, о "сущности" т.е. и об атрибуте "Федя" будут другие "сущности" (таким образом сохраняя ее "в реальном мире"). СК попросту свободен от иных функций, кроме как представлять собой идею уникальности записи внутри модели, но освобожден от попыток привязать к нему ф-ю обеспечения однозначности привязки к "физ. сущности реального мира". (ЕК, как замечено выше, не освобождает от возможности подмены "сущности". По крайней мере не всегда, и почти всегда - с сопутствующими осложнениями).

странные вещи пишет некий чел про организацию классов и естественность ключей. тип ключей (естественный/суррогат) тут вообще никоим раком. Тут уж вопрос о составном ключе. Составной "Суррогатный" ключ в предке (id_typ,id) и такие же в потомках, но с ограничением на величину id_typ = 1|2|3...|id_classN решает вашу "задачу" "чиста на констрайнтах" не уверен, правда, что это хорошее решение (кажеца глупым хранить поле с константным значением в таблице). (да и триггер на раздачу уникумных id тут гораздо лучче).

gardenman>кажеца глупым хранить поле с константным значением в таблице
Действительно кажется глупым, но увы, вешать обеспечение целостности на триггеры - это всегда медленнее и менее надежно чем PK/FK.
не знаю. Думаю все зависит от реализации СУБД. Вот например в постгрессе чек/ФК - тоже хранимка (только написанная разработчиками). С другой стороны там нет надобности заниматься "звездатым" наследованием. Там есть свое. И ваша таблица "предок" может быть вообще "виртуальной" (в ней может не быть ни одной записи) а SELECT * FROM предок; вернет всех потомков (причем вы можете получить и имя таблицы - "истинного" владельца записи в таком запросе
SELECT *, tablenaime FROM предок;

ЗЗЫ опять таки обращаю внимание, что "составной" и "суррогат" - немного разные вещи (я пытался это "немного "оспорить" в другом топике, но это не к этому разговору).

наврал, вы получите tableoid. из которого получается tablename сверткой с pg_class по tableoid
SELECT .... c.relname AS tablename FROM ... JOIN pg_class AS c USING(tableoid)

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

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

Владимир П. Очень часто меняют международный код валюты? По нескольку раз на неделе приходится переименовывать общепринятые обозначения марок стали в справочнике материалов?
гхм. Вот думаю, насколько ваши "естественные" атрибуты "естественны" .
Вы видимо совершенно правы, когда говорите о совершенно _суррогатных_ атрибутах (и "код валюты" и "обозначения марок стали в справочнике материалов" абсолютно модельные, суррогатные вещи, неприсущие как таковые ни сталям, ни валюте) . Так же например в системах учет движения по "счетам учета" "счет учета" (т.е. его "наименование" - "символьная запись") вещь абсолютно суррогатная (в течении года к тому же и неизменная, и без своего "именования" даже и не существующая (правда существует "нечто" ассоциированное с этой абстракцией,но не будем углубляцца)). Т.ч. в системах учитывающих "модельные" сущности ("счета учета", "коды валют" и т.п.) использование их в качестве ПК таки возможно оправдано. (надо оценить цену джойна - с одной стороны, и длину полей (а сталобыть и цену записи/чтения хранения) ЕК vs СК - с другой).


2. валидатор. Для валидации есть куча инструментов. Те же Уникью, к примеру, Not NULL и т.п.. Т.ч. это не аргумент в нашем случае.

Владимир П.Заданы предметной областью, а следовательно -- естественны. гхм. "Атрибут" сущности (т.е. св-во "объекта реального мира") - естественен, если он (оно) не моделен. Если "предметная область" сама по себе - модель то в ней уже есть "модельные" суррогаты (каковые не есть "естественные св-ва объектов реального мира") - и они то и выступают _для вас_ в качестве ЕК.

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

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

guest_20040621 Например, первые две цифры - номер региона. Вы уверены, что остальная часть номера абсолютно неинформативна? кажеца есть форма собсн-сти, а еще там и контрольная сумма кажись была зашита (если я с номером страховых не путаю).
=>Смена региона (формы собсн-ти) требует сменять ИНН=> юзать ИНН как пк стремно.