sphinx_mvalexeyvgпропущено...
Странно, я разве писал в этой теме про почтовые коды и использование их в качестве ИД??? По моему, вы меня с кем то перепутали.

Я никого ни с кем не перепутал - разве что у кого-то раздвоение личности... Тему почты кто поднял?
Ну, так вот, практически ЕДИНСТВЕННОЕ, что есть в ЛЮБОЙ почтовой системе, и что можно было бы притягинуть за уши здесь на тему "естественных ключей" (для "более других" систем) - это почтовые индексы...Да почему же единственное??? Что, любая база почтовой системы - это одна таблица, что ли???

Я, например, имел в виду ИД почтового отправления. Это естественный ключ по отношению конкретной почтовой БД, где обрабатывается почтовое отправление, и суррогат в "мировой почте" в целом (как и любой естественный ключ является на каком то уровне суррогатом).

sphinx_mvalexeyvgХотя это интересная тема, дискуссионная. Но не для этого топика, который, кстати, посвящён с самого начала исключительно суррогатным ключам (а именно техническим деталям их генерации), но группа товарищей немедленно начала холивар о своём :-)

Если кто не в курсе, почтовый индекс - суррогат, детали генерации и сопровождения которого ОЧЕНЬ ИНТЕРЕСНЫ при использовании в качестве ключей в "сторонних системах".Безусловно, суррогат.
Собственно, любой естественный ключ - это суррогат на каком то уровне, это же очевидно.

А насчёт дискусионности и насчёт использования почтового индекса в качестве естественного ключа - нужно просто правильно определять сущность, для которой этот ключ используется.

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

sphinx_mvНа всякий случай - во избежание излишней взволнованности.. Суррогаты - это тоже ключи, уникальность которых можно гарантирована ТОЛЬКО ВНУТРИ какой-то конкретной системы/комплекса систем. ЗА пределами - это уже просто некий "описательный атрибут".Можно поменьше острот и капслока? Нужно понимаеть, что такой стиль сразу говорит о некомпетентности человека или как минимум о неумении объяснить свою позицию.
sphinx_mvalexeyvgЯ, например, имел в виду ИД почтового отправления. Это естественный ключ по отношению конкретной почтовой БД, где обрабатывается почтовое отправление, и суррогат в "мировой почте" в целом (как и любой естественный ключ является на каком то уровне суррогатом).

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

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

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

sphinx_mvНе хочется себя цитировать, но, наверное, придется... Ну, я уж как-нибудь "близко к тексту"
"Преимущества естественных ключей их любители могут продемонстрировать не более чем на 3, максимум, 4 таблицах со связями между собой".
Именно Вас это СИЛЬНО возбудило и Вы привели пример с почтой.

Ну, так вот... Дабы Вы БЫЛИ В КУРСЕ,Вы хоть можете обосновать своё утверждение, без клоунских причмокиваний? Я честно говоря не понимаю преимуществ естественных ключей для "3, максимум, 4 таблицах", и нигде не видел каких то теорий на эту тему.
sphinx_mvНу, так вот... Дабы Вы БЫЛИ В КУРСЕ, "почтовый индекс" является неким кодом геграфической зоны, области, населенного пункта и т.п., применяется для облегчения сортировки почты в целях ее доставки. Иногда почтовый индекс предоставляется отдельным организациям или лицам с большими объемами корреспонденции. Таким образом, имеем соотвествие 1 таблица "справочник индексов зон доставки" и 1 таблица - адрес получателя или отправителя, где индекс может использоваться. А может и НЕ использоваться. Таким образом ОБЩЕЕ количество таблиц, хоть как-то связанных с этим "естественным ключом" составило аж целых 2 (две)... Как только необходимо выходить ЗА рамки почтовой системы одной отдельно взятой страны "естественный ключ",
представленный почтовым индексом ПЕРЕСТАЕТ быть ключом. Т.е. - СОВСЕМ... Вот такие "преимущества", однако...
Тут бы еще начать "усиленно вспоминать", сколько раз за последние несколько лет (хотя бы 10) менялись индексы населенных пунктов внутри отдельно взятых стран - и станет совсем "весело"...Зачем писать про очевидные вещи, разве с этим кто то спорил или утверждал обратное?

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

Сам по себе почтовый индекс никакой он НЕ кандитат на гордое звание "естественный ключ"!
Внутри почтовой системы он суррогат. Вне почтовой системы, в лучшем случае - часть составного ключа.Не понял, почему "Внутри почтовой системы он суррогат"? Почтовая система (в смысле, софт, написанный разработчиком для какой то частной или государственной почтовой компании) использует кем то установленные индексы, а не генерит их сама.

sphinx_mvНа вопрос какие преимущества есть у естественных ключей перед сурогатами - ВНЯТНОГО ответа НИ РАЗУ НЕ последовало...По моему, тут уже писали про это преимущество. Естественный ключ идентифицирует реальный объект, а суррогатный запись в базе данных.

Безусловно, можно сделать это поле не естественным ключём, а просто атрибутом, но тем не менее именно это поле будет идентифицировать запись.

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

softwareralexeyvgЕстественный ключ не идентифицирует реальный объект,
Так ближе к истине.Весомый аргумент.