PVP В качестве примера, пусть попробует специалист предложить ключ для абонентов телефонной компании лучше, чем номер телефона. Или даст аргументы для операторов компании делать поиск абонента по некоторому ID.
на моей памяти 2-ды менялся номер телефона. (и у массы соседей тоже). кхм. идиотское предложение, имхо. But - "Ничего личного".

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

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

Владимир П. 1024
таблица "игроки" вероятно связана с таблицей "игры". При сменен ника с
УльтроКиллер на УльтроМегаКиллер нужно будет поменять ник этого игрока в
таблице "игры" везде где он встречается и потом в таблице "игроки"
И в чём проблема?
проблема в том, что не замочив всех, кто в танке, "УльтроКиллер" не достоин звания "УльтроМегаКиллер".
А так - никаких проблем

авторЭто такая опция к ограничению ссылочной
да с этим никто не спорит. Просто оцените стоимость апдейта, если ваш пк входит скажем в ~10**5 записей различных детей. А если еще и злоупотребляете вхождением его (на стороне связанных записей) в составные ключи/индексы (которые видимо придется перестраивать)? Что должны делать другие ползатели в моменты блокировки массы записей в связанных таблицах (даже версионник, мне кажется, не пишет в изменяемую запись?).

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

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



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

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