vadiminfosphinx_mvПример естественного ключа, который не представляет собой СУРРОГАТ - СЛАБО?
Соответственно, правильнее звучало бы - "естественные" СУРРОГАТЫ решают проблему СУРРОГАТОВ...

Возможно када-то понятние "естественные" СУРРОГАТЫ буит иметь значение. Но до выяснения новых обстоятельст, возможно, предпочтиельнее ограничиться тока: естесвенные, суррогатные.


А чего это вдруг "ограничиваться"?

По суррогату Вы НИКОГДА не скажете, что он из себя представляет. Ну, вот комбинация "А12345678" - это что?
Я-то знаю, что это пример номера документа... А какого типа документа номер?.. И чей он?..
А существует ли документ с таким номером вообще?..
Для этого нужно лезть в "бумажку"/таблицу, где он зарегистрирован. И там он - суррогатный... И что прикольное - это ТОЖЕ часть ПРЕДМЕТНОЙ ОБЛАСТИ...
А так все замечательно начиналось как "естественные ключи"...
vadiminfo(Нет, конечно, я видел попытки налабать что-то среднее между суррогатами и естественными: мнемоники - сокращения
Т.е. сокращения придуманные проггерами. Они для предметеной области суррогаты - нет таких свойств у объектов, но для проггеров они типа естественные - они им подскажут некий смыл. Но поскоку это было тока для справочников, то моно проигнорировать.)

ЛЮБОЙ код, созданный и хранящийся в справочнике (реестре, и тд и тп) и получаемый ТОЛЬКО оттуда - суррогатный...
Даже если это реестр ведется вахтером на клочке бумаги.
sphinx_mvА можно я угадаю, чтов доке должны быть прописаны приборы с "номерами" A121 или А123?
Или АС11 или АС13? И как же я так "случайно" их угадал?
vadiminfo
В доке ошибок не было:"А122" или "АС12". Ну пусть это считывалось считывающим устройством.
Если Вы считаете lfyyst суррогатами, в зависмости от знаков значений, а не по их отсутсвию в реальном по отношению к БД мире,
то тада, возможно, Вы не совсем относитесь к лагерю сторонников суррогатных ключей.

Код устройства ОТКУДА ПОЛУЧЕН? Из "бумажки"... КАК на "бумажку" попал? Номер взят с "ПОТОЛКА"...
Соответственно, СУРРОГАТ!
Бумажка - точно такая же часть информационной системы, как и таблица на сервере БД.
Это только ДРУГОЙ СПОСОБ ХРАНЕНИЯ информации... И БД даже имеет ССЫЛКИ на эту "бумажку" - и что с того, что они поддерживаются "ручками"?
vadiminfosphinx_mvИ, обращаю внимание - сами по себе комбинации "А122" или "АС12" не несут НИКАКОЙ смысловой нагрузки.

Вообще-то несут информаци об устройстве юзерам: участвуют в описании устройства. Живут вне БД об этой предметной области.
А суррогат тока идентифицирует запись в БД. Как тока он начнет идентифицировать что-то реальное, он перестанет быть суррогатом. И все.

БРЕД!!!

Суррогат ВСЕГДА остается СУРРОГАТОМ.
Поговорите с бухгалтером на тему плана счетов и проводок... Или просто послушайте как они между собой общаются на эту тему...
Бухгалтеры практически ОТКРЫТЫМ ТЕКСТОМ оперируют суррогатнымии НОМЕРАМИ счетов бухгалтерского учета...
Но от этого СУЩНОСТЬ номера счета НЕ меняется - суррогат как был так и остался...
vadiminfo
sphinx_mvТочно как и любой другой суррогат, пока про него не скажут, что "этот номер означает это"...

Ну если Вы заставите юзеров их задокументировать, привесить бирку на прибор: проведете типа объестесвливание суррогата, он просто перестанет быть суррогатом.

НЕ ПЕРЕСТАНЕТ!
Это всего лишь означает что кто-то начинает использовать значение суррогатного первичного ключа в информативных запросах.
Мне ткнуть пальцем в того, кто был активно против такого применения по сути "автоинкрементов"?

В плане приборов и использования их кодов естественным ключом для измерительного прибора будет нечто типа амперметр стрелочный "Х.З. какой марки", расположенный "где-то там" и т.д. и т.п... Все остальные варианты - нормализация в использованием суррогатов...
vadiminfosphinx_mvГде гарантия, что при потере данных из первичной таблицы при этом не потерялись данные в дочерней?
Кто сказал, что при этом не сработают так Вами любимые каскадные операции при обновлении и удалении ПК, когда


Я же не говрил о достоинстве на все случаи. А тока на вышеназванный.

На вышеназванный? Песочница!.. Даже на поделку студента-первокурсника не тянет...
Информационная система, в которой запросто можно положить на появление записей в дочерих таблицах, не имеющих родителей, положительных эмоций не вызывает!
vadiminfosphinx_mvМаркеры... Что они означают ВНЯТНО рассказать можете?

Это какие-то данные, которые маркируют там что-то. Т.е. в БД будут естесвенными. Если Вы такие "суррогаты" имели в виду када говрили об их достоинствах, то наши мнения совпадают. Просто я назывваю это естесвенными.
Маркеры, которых НЕ СУЩЕСТВУЕТ "в природе" НИКОГДА не будут естественными...
Предметная область, внутри которой используются эти маркеры ВКЛЮЧАЕТ в себя и ту часть, где эти маркеры СОЗДАЮТСЯ и ХРАНЯТСЯ.
С учетом СПОСОБА появления маркеров - они СУРРОГАТЫ.
Иначе можно "доболтаться" до того, что для любой дочерней таблицы в любой связи родительский ПК - "естественный"...
А че нет? Он же не создан в "предметной области", описываемой и реализуемой именно этой одной конкретной (дочерней!) таблицей!

vadiminfosphinx_mvКод устройства ОТКУДА ПОЛУЧЕН? Из "бумажки"... КАК на "бумажку" попал?
На заводе, наверное, присвоили. Если у юзеров есть интерес откуда он туда попал, это буит хранитьсмя в БД.

Вы че хотите сказать что это суррогат?

В данной БД это естесвенный атрибут. Суррогат - искусвенный в данной БД (а не происхождению вообще, не по испльзуемым в нем знакам). Таког свойства просто нет у объектов данной ПО. А Код есть: естесвенный.

Впрочем, как хотите. Вам типа видней.

Но, скорей всего, Вы не сторонник ни суррогатов, ни , наверное, естесвенных в обычном понимании.
Я думал, что общаюсь со сторонником суррогатных ключей.

40 лет назад, когда Кодд разрабатывал реляционную теорию, каждая отдельно взятая база данных была абсолютно не связана с другими - даже просто связать между собой компьютера было не просто проблемой, а ОЧЕНЬ БОЛЬШОЙ проблемой. Тогда можно было разделять естественные и суррогатные ключи по принципу "получен снаружи" или "сгенерирован внутри" информационной системы.
Сейчас, когда строятся единые информационные не только отдельно взятых стран, но и информационные системы объединющие несколько государств одновременно, РАЗНИЦЫ между естественными и суррогатными ключами становится все меньше и меньше. И многие примеры возможных "естественных" ключей в единых (или стремящихся к тому) базах данных по сути генерируются как суррогатные. Более того, особых проблем, чтобы обеспечить доступ к "первоисточнику" этой информации НЕ представляет.
В-общем, в мире ПРАКТИЧЕСКИ НЕ ОСТАЛОСЬ вариантов естественных ключей, которые НЕ представляют собой СУРРОГАТЫ.
Соответственно, особо упираться, что "номер паспорта" - это естественный ключ и никакой он "не суррогат", может либо проектировщик "детской песочницы", либо человек, который не видит дальше собственного носа...

softwarersphinx_mvВ-общем, в мире ПРАКТИЧЕСКИ НЕ ОСТАЛОСЬ вариантов естественных ключей, которые НЕ представляют собой СУРРОГАТЫ.
"Суррогатность" не является неотъемлимым свойством значения, она выражает взаимоотношения между значением и базой. Ключ может быть естественным в одной базе и суррогатным в другой, фактически "суррогатный" следует читать как "принадлежащий этой базе".
Когда несколько больших баз данных объединены между собой и используют один и тот же идентификатор-суррогат - про какую БД мы говорим как о "владельце" (при такой постановке), если "База" фактически только одна?

vadiminfosphinx_mv...Сейчас, когда строятся ... ...

Хде-то слышал. Скорей всего, нуно заменить в речи эту фразу.

От Вас уже слышалось про то, что "без пенсионного номера на работу не принимают" - как оказалось, ТУФТА!
Совершенно неудивительно, что Вам не известно о том, что только в России в единый реестр информационных ресурсов объединяются 11 баз данных...

softwarersphinx_mvКогда несколько больших баз данных объединены между собой и используют один и тот же идентификатор-суррогат - про какую БД мы говорим как о "владельце"
Про ту, которая их выдаёт.

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

ViPRosvadiminfo,

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

vadiminfoВ общем типа высокая кавалификация в проектирвании БД, это када не понимишь отличия в каких-то простых понятиях, типа суррогатнгый и естесвенный ключ, придумываешь им тада свое, а в ходе типа обоснования этого своего, должны всплыть черные ящики, или там, к примеру, мешочки. Ну и, конечно, нуно много рассуждать о квалификации о профессионализме.
Нескромно? А что делать? Иначе как поймут, что кавлификация высокая у самого то?
К вопросу о профессионализме. Его уровень определяется не степенью заумности рассуждений, а сложностью реально решаемых реальных задач...
Мне всегда было смешно с примеров и аргументов сторонников "естественных" ключей, когда они демонстрируют, якобы, преимущества естественных ключей над сурогатами на связях 3, максимум, 4 таблиц - на ТАКИХ задачах еще МОЖНО как-то это попытаться продемонстрировать... И только НА ТАКИХ!
Хранение анкетных данных клиента (будь то физическое или юридическое лицо) приходится разворачивать чуть ли не на десяток таблиц... И это даже без учета справочников... Даже такой структуры (местами) маловато для "полного счастья"...
"ПроЭкт" на 3-4 таблицы - он на "задачу", тем более, "реальную" не дотягивает... Не говоря уже об ошибках в рассуждениях, которые "проЭктанты" допускают...

alexeyvgsphinx_mvМне всегда было смешно с примеров и аргументов сторонников "естественных" ключей, когда они демонстрируют, якобы, преимущества естественных ключей над сурогатами на связях 3, максимум, 4 таблиц - на ТАКИХ задачах еще МОЖНО как-то это попытаться продемонстрировать... И только НА ТАКИХ!Преимущества естественных ключей как раз неплохо проявляются в сложных системах, когда система делалась много лет, работает во многих филиалах, да ещё разные части системы работают на разных платформах и разрабатывались разными подрядчиками. Для примера возьмите авс крупного банка (типа сбера), почта США, SWIFT.

"В то время как космические корабли бороздят просторы космоса"... Угу...

Простой вопрос - по какому принципу формируются почтовые коды хотя бы в США, случайно, не расскажете?
А про "неизменность" (и, следовательно, "однозначность при идентификации") почтовых кодов, хотя бы теоретически, знаете - ну, хоть в тех же Штатах? И, заодно, вопрос "на засыпку": что вы (теоретически) слышали про совместимость почтовых кодов разных стран при использовании в ОДНОЙ(!) "большой" системе?