Комментарии 25
Строго говоря, настоящих Natural ID не бывает. Любой объект может иметь такие же характеристики, как другой аналогичный объект. Natural ID это такой же искусственный ID, только придуманный для учета в другой системе или вообще не в компьютере.
Кроме практических нюансов есть теоретическая причина, почему не стоит использовать Natural ID. Идентификатор объекта имеет внутреннюю природу, он нужен для самой системы, чтобы она могла различать объекты или распознавать один и тот же объект в разные моменты времени. Поэтому неправильно использовать для этого идентификаторы из внешних систем. Последовательные ID дают гарантированно разный идентификатор для новых объектов, и с ними проще работать с технической стороны, поэтому они удобны.
Согласен со статьей, не нужно пытаться найти в данных естественный ключ, чтобы использовать его в качестве первичного.
Строго говоря, настоящих Natural ID не бывает. Любой объект может иметь такие же характеристики, как другой аналогичный объект. Natural ID это такой же искусственный ID, только придуманный для учета в другой системе или вообще не в компьютере.
Именно! Всегда это говорил коллегам на поползновения использовать естественные первичные ключи. Испльзуя естественный ключ вы, на самом деле, используете искуственный ключ из другой учётной системы, которую вы НЕ КОНТРОЛИРУЕТЕ. И зачем вам такая зависимость?
С естественными ключами бывает ещё проще проблема: вот казалось бы куда уж естественнее ключ - серия/номер паспорта РФ. Даже оставляя за кадром как раз непостоянство законов человеческих, где сама система нумерации может поменяться в любой момент, что делать в том случае, если оператор ошибся при вводе этого самого естественного ключа? Редактировать ключ нельзя, он уже защит в какие-то ещё связи. Ничего нерешаемого, но морока
Нельзя же.. меняем 20,45 лет, смена фамилии, утеря. И да, криво вносим или OCR.
Справедливости ради... Если это идентификатор именно паспорта, а не его владельца, то любые замены не проблема. А вот OCR дааа
На мой взгляд, ключевая мысль статьи даже не про Natural vs Surrogate Key, а про то, что Primary Key — это контракт системы, а не просто способ обеспечить уникальность строки.
Пока приложение живёт внутри одной БД, кажется, что изменить PK — не такая уж проблема. Но как только появляются внешние сервисы, кэш, Kafka, CDC, S3, аналитика или просто ссылки в других БД — PK становится частью публичного API.
Именно поэтому стоимость ошибки здесь растёт не линейно, а практически экспоненциально.
Не стоит из своего ушибленного пальца делать религию с запретом на молотки.
Мир намного больше, чем вы себе можете представить - кто-то может неплохо уметь обращаться с молотками.
Overhead на реализацию и поддержку решения, где гвозди забиваются ватными тампонами, чтобы не ушибить ваш палец, может в итоге вырасти намного в больший размер за пределами вашей ответственности и так как вы это не видели, вам кажется что всё ок.
Иногда заказчикам и эффективным менеджерам нужно говорить «нет». Когда вам говорят «а может мы можем как-то сделать, чтобы трактор перепрыгивал небольшие заборы высотой всего лишь до 3х метров?» - нужно сказать «нет», а не закладывать в каждый трактор изначально турбореактивный двигатель.
Даже с вашим примером с емэйлом как идентификатором пользователя если вы начинаете любые хотелки удовлетворять, в итоге получается, что нужно городить интерфейсы по слиянию пользователей и разделению, сценарий подтверждения смены емэйла, так как все системы сейчас историчны и требуют siem и отслеживания, гораздо сложнее отслеживать потом действия. Из своей практики могу привести пример, как при инциденте было убито куча человеко-часов на выслеживание по системе пользователя, который несколько раз менял в учётке ФИО и логин и был футбол с ИБ и менеджментом «вы мне не то прислали, это про Петю, а нам про Васю надо!!!», «но он был тогда Вася, а сейчас Петя!».
Иногда, если вас просят сменить айди экаунта заказчика, в котором три шестёрки, потому что заказчик суеверный, нужно говорить «нет». Или смириться с тем, что он создаст новый, а старый будет похоронен без связи с новым. Это дешевле, чем везде на будущее добавлять гибкость, DI, ключи в виде uuid, которые пользователи в выгруженных таблицах не могут глазами быстро сравнить и тд, бороться с ошибками и зализывать старые места, которые полагались на «on conflict do nothing”, а вы вдруг решили удалить индекс и сделать это поле не уникальным, бороться с join-ами и размерами бд и бэкапов, потому что «ну вот, трактор прыгает, но чёт теперь всё медленно работает» и тд.
С точки зрения юзеров, необоснованные констрейнты (не разрешим поменять емейл, потому что мы решили сделать из него primary key) выглядит банальным неосиляторством. Точно так же как запрет пробелов в имени пользователя, или запрет знаков <> в тексте комментария.
Это очень забавно, что приводится один контраргумент по одному больному сценарию и он расширяется на какие-то кавычки в текстах комментариев. Как они к праймари Кей относятся?
И на самом деле мнение 1% юзеров не делает погоды. Ибо вас всегда можно обвинить в неосиляторстве и всегда кто-то это сделает.
Вы делаете систему для бизнеса, или чтобы ни у кого шанса не было вас обвинить, что вы не смогли сделать старшип для вспахивания поля путём приземления юзом на плуг?
Кодируйте UUIDv7 в выгузках в компактный текстовый формат. А вообще сравнивать идентификаторы глазами - это плохая идея. Пользователи вообще не должны видеть идентификаторы, ведь им нужны бизнес-данные. А для внешних потребителей нужно использовать стандартизованные классификаторы и преобразовывать суррогатные ключи в натуральные, действительные в отчетную дату.
Натуральным id не хватает натуральности и полноты. Это результат спешки, глупости, жадности айтишников и заказчиков стандартов.
Вот возьмём ИНН. Чтобы он стал хорошим id, нужно было всего лишь чуть дольше думать, а затем утвердить стандарт в ООН, убрать регион, но добавить пару-тройку разрядов на код или координаты места рождения. И тогда ИНН стал бы уникальным. Его удалось бы присвоить даже всем умершим, а родившимся давать автоматически по месту рождения, полу, timestamp. С юр лицами - аналогично.
Это сэкономило бы миллиарды долларов. Кто виноват в плохих, слабых стандартах, которые ломаются за несколько лет? - айтишники. Только они могут здраво оценить матем. ёмкость кодификаторов.
Впрочем, есть примеры, когда стандарт пережил 45+ лет, не сломавшись. MIDI с невероятно медленным потоком 1500 бод до сих пор правдоподобно передает всю музыку, путем грамотного уплотнения и 16-ричной системы исчисления.
Насчёт midi - вы же в курсе наличия внутри разных версий стандарта и несовместимых расширений, из-за которой что-то может не играться или играться не так, как задумал автор? Хотели бы жить с ИНН, построенным по тому же принципу?)
Стандарт один, расширения от Roland были не фатальны, обратная совместимость всегда была и будет. Синтезатор 1986 г будет играть по кабелю из 2026 г, будучи соединённым с ПК. И синт 2026 г.в. через кабель 1986 г.в. будет звучать теми же звуками, которые пошлет софт на ПК. И да, софт 1996 и 2026 с миди работает тоже одинаково. Потому что в самом стандарте передачи не меняли ничего: ни разъемы, ни скорости, ни биты. Но самое удивительное - первый и единственный по сути стандарт придумали задолго до того, как появились первые поддерживающие его цифровые устройства . То есть это была полностью умственная инженерная проработка на перспективу.
А вот “список дружбы” - GeneralMidi - да, смешон. Было в 128 патчей всунуто много нац инструментов со всего мира, половина из которых на практике никогда и никем не использовалась. Но не потому что ошиблись, а потому что не предвидели взрывной рост и появление FM, WT, Granularity-синтеза, сэмплеров, рэпа, битбокса итп.
Когда то себе сохранял такую памятку https://des1roer.blogspot.com/2016/01/blog-post_95.html
И вот там решили использовать email в качестве natural key. Вы пишите сервис, который оркестрирует подписки пользователя на те или иные сервисы в рамках экосистемы. И вот вам надо для своих операций получить профиль пользователя из вот этой смежной вам системы. Каким образом вы его получать будете? Конечно же, по email! Это же “уникальный ключ”.
Лично сталкивался с тем, что на свежий ящик %.mail.ru начали приходить уведомления от одного регистратора домена, связанные с доменом другого их клиента, причем не самого завалящего в Москве в то время. Т.е. E-mail не такой уж и уникальный.
Автор вообще не понимает, что такое натуральный ID. Сам дискурс, что его надо выдумывать, противоречит их концепции и в ход идут примеры ненатуральных ключей, вроде e-mail или паспортов, которые идентификаторами персоны не являются в принципе, это ассоциированные сущности. Натуральный, это когда вы берёте код страны по ISO 3166, БИК банка и т.п. За каждым натуральным ID существуют целые организации, управляющие соответствующими справочниками и единственным аргументом менять их на суррогатные ключи является вопрос оптимизации данных при высокой IO-стоимости ключа, особенно в связанных таблицах.
Сам дискурс, что его надо выдумывать, противоречит их концепции
“код страны по ISO 3166, БИК банка” никто не выдумывал, они сами появились?
За каждым натуральным ID существуют целые организации
A Relational Model of Data for Large Shared Data Banks - E. F. CODD
“In the example above, part number would be a primary key, while part color would not be.”
“In the relation supply of Figure 1, the combination of supplier, part, project is the primary key.”
“employee (serial#, name, manager#, managername) with serial# as the primary key”
“код страны по ISO 3166, БИК банка” никто не выдумывал, они сами появились?
Все ключи кто-то выдумал. Вы же не полагаете, что натуральные - природного или божественного происхождения? Поэтому всё сводится к уровню их определения. Для ISO код 643 применительно к РФ был очевидно суррогатным, поскольку нет такой f, что f(РФ) = 643 и далее по всему списку. Для вас, как проектировщика БД, он будет натуральным, поскольку определён индсутриальными стандартами, то есть средой, бизнес-доменом. Натуральный/суррогатный = среда/разработчик.
A Relational Model of Data for Large Shared Data Banks - E. F. CODD
Как мне интерпретировать статью, где натуральные или суррогатные ключи упомянуты ровно ноль раз, в контексте моей цитаты про таковые? А также хаотические вырезки из текста, где природа “part number” никак не определена, а я говорил исключительно о ней.
Сам дискурс, что его надо выдумывать, противоречит их концепции Все ключи кто-то выдумал.
У вас противоречие в концепции.
Вы же не полагаете, что натуральные - природного или божественного происхождения?
Я нет, это вы так полагаете, судя по вашему первому комментарию.
Для вас, как проектировщика БД, он будет натуральным, поскольку определён индсутриальными стандартами
Индустриальность стандарта не входит в критерии первичного ключа.
то есть средой, бизнес-доменом
Вот именно, среда и бизнес-домен могут быть любыми, главное что они внешние по отношению к проектируемой системе. Определять их может любая другая система, а не только “целые организации, управляющие соответствующими справочниками”.
Как мне интерпретировать статью, где натуральные или суррогатные ключи упомянуты ровно ноль раз, в контексте моей цитаты про таковые?
Так, что один из авторов теории реляционных БД называет первичным ключом произвольный набор полей, которые уникально идентифицируют запись. Общепринятого разделения на натуральные и суррогатные на момент написания той статьи еще не было. Выделение отдельно суррогатного ключа появилось позже в “Relations and Entities” (1976) и “Extending the database relational model to capture more meaning” (1979). То есть все ключи натуральные, если они не суррогатные.
У вас противоречие в концепции.
Потрудитесь пояснить, где вы нашли противоречие? Природа ключа контексто-зависимая. Авторы БИКа выдумали ключ, в этот момент он суррогатный. Вы его использовали в своей системе как натуральный. Если вы станете выдумывать в своей системе новые ключи, они будут суррогатными. Для той системы, которая будет использовать вашу кодификацию, они могут стать натуральным. Природа ключа определяется средой. В идеале - естественной, но там очевидных ключей нет, поэтому в мире выстраиваются различные организационные иерархии (организация - это прежде всего способ упорядочивания, а не юридическое лицо), чтобы вести кодификацию.
Я нет, это вы так полагаете, судя по вашему первому комментарию.
И как из моего первого комментария, что натуральные ключи не выдумывают это следует? Вам не кажется, что выдуманное по определению являетеся суррогатным? Как из сути, так и из этимологии этого слова?
Индустриальность стандарта не входит в критерии первичного ключа.
Как это связано с тем, что я сказал про возможность использования ISO 3166 в качестве натурального ключа для стран? Вы пытаетесь опровергнуть то, что я не утверждал. Может хотите сказать, что коды ISO не являются хорошим, авторитетным кандидатом на эту роль?
Вот именно, среда и бизнес-домен могут быть любыми, главное что они внешние по отношению к проектируемой системе. Определять их может любая другая система, а не только “целые организации, управляющие соответствующими справочниками”.
Так это мои слова, что “средой, бизнес-доменом”. Цитата, которую вы вырвали из контекста, говорила лишь о том, что некоторые справочники с натуральными ключами уже ведутся большими организациями. И очевидно, что репутационный и качественный индекс у них достаточно высоки. Тое есть вряд ли появится две страны с одинаковым ISO-кодом или одна страна с двумя или страна завтра поменяет свой ISO-код. Но взять на себя “организацию справочников” может любая система.
Так, что один из авторов теории реляционных БД называет первичным ключом произвольный набор полей, которые уникально идентифицируют запись.
Я уже давно хотел поинтересоваться, отличаете ли вы первичный ключ от натурального/суррогатного. Оказывается нет, в принципе. Первичный ключ - это констрейнт, который в каноническом виде пишется как ALTER TABLE ... ADD CONSTRAINT ... PRIMARY KEY ... . Он может накладываться на натуральный ключ, суррогатный, композитный, вы можете сделать первичный ключ по хэшу содержимого или иной функции. Натуральный/суррогатный ключ - это данные, отражающие природу появления этого ключа. Они возникают до первичного и содержатся непосредственно в CREATE TABLE. У меня в одной таблице может быть, скажем VIN автомобиля, являющийся его натуральным ключом, а может быть простой автоинкремент - суррогатный ключ, а PK я могу создать по любому из них. Я обсуждаю первую фазу - данные, а вы пытаетест навесить констрейнты. На что?
Выделение отдельно суррогатного ключа появилось позже в “Relations and Entities” (1976)
Вы статью хоть читали? Она фокусируется на концепции суррогата, поскольку не всегда можно идентифицировать сущность по совокупности ей аттрибутов и возникала проблема определения тождественности при изменении этих аттрибутов. И, как говорили авторы: “A key is still needed to uniquely identify the surrogate.”. Природу возникновения ключа они вообще не обсуждали, главным требованием была неизменяемость.
То есть все ключи натуральные, если они не суррогатные.
Это круговой, неоперациональный классификатор, основанный на недоопределённом предикате. Из категории “пациент либо жив, либо мёртв”.
Потрудитесь пояснить, где вы нашли противоречие?
Я уже пояснил в предыдущем комментарии. Сначала вы говорите, что выдумывать натуральные ключи нельзя, потом говорите, что их тоже кто-то выдумал.
Вы же не полагаете, что натуральные - природного или божественного происхождения?
И как из моего первого комментария, что натуральные ключи не выдумывают это следует?
Так и следует, если их никто из людей не выдумывает, то они природного или божественного происхождения. БИК кто-то выдумал, или он сам появился?
натуральные ключи не выдумывают
Автор статьи нигде и не говорил, что их надо именно выдумывать, в том смысле, который подразумеваете вы. С чем вы спорите? Назначить набор несуррогатных атрибутов записи первичным ключом это именно то, что делает Кодд в своих примерах. Это будет именно натуральный первичный ключ, просто по определению. Критерия “индустриальности” и “справочника” он там не указывает, он назначает их произвольным образом.
- Натуральный, это когда вы берёте код страны по ISO 3166
- Для вас, как проектировщика БД, он будет натуральным, поскольку определён индсутриальными стандартами
- Индустриальность стандарта не входит в критерии [натурального] первичного ключа.
- Как это связано с тем, что я сказал про возможность использования ISO 3166 в качестве натурального ключа для стран?
Так и связано, вы сказали, что он натуральные потому что определен стандартами. А он натуральный только по тому факту, что является частью атрибутов записи, значения которых приходят извне системы, а не является созданным внутри системы. Индустриальность не входит ни в критерии первичного ключа, в том числе натурального.
За каждым натуральным ID существуют целые организации, управляющие соответствующими справочниками
Цитата, которую вы вырвали из контекста, говорила лишь о том, что некоторые справочники с натуральными ключами уже ведутся большими организациями.
Не вырывал я ничего из контекста. Вы прямым текстом заявили, что натуральным может быть только тот ключ, который задается организациями в справочнике, а любые другие это ненатуральные, даже если они не генерируются внутри системы. Это ложное утверждение, поэтому я на него возразил. Ни в одном общепринятом определении натурального ключа “организации, управляющие соответствующими справочниками” не указывается как критерий.
отличаете ли вы первичный ключ от натурального/суррогатного. Оказывается нет
Прежде чем переходить на личности, потрудитесь привести ссылку на материал, где указано определение первичного ключа, которое вы написали. А то может оказаться, что это вы чего-то не понимаете.
Первичный ключ - это констрейнт, который в каноническом виде пишется как ALTER TABLE …
Он может накладываться на натуральный ключ
Нет. Первичный ключ это набор атрибутов записи, который уникально ее идентифицирует. Он может быть суррогатным или натуральным, но они оба по определению это первичные ключи. Это понятие из теории, а не выдумка разработчиков какой-то отдельной СУБД.
A Relational Model of Data for Large Shared Data Banks - Codd
Normally, one domain (or combination of domains) of a given relation has values which uniquely identify each element (n-tuple) of that relation. Such a domain (or combination) is called a primary key.
поскольку не всегда можно идентифицировать сущность по совокупности ей аттрибутов
Как это противоречит тому, что я сказал про появление термина surrogate?
Феереческий текст, надо проверится на сдвг. Тем не менее, амазон использует их и даже рекомендует в некоторых случаях. Причин не делать так полно, и Рей Далио тут не причем. Псевдо-натуральные айди удобны юзерам - они выбирают теги, лейбы и подобные value-объекты, а уж как оно будет сделано внутри дело десятое.
Натуральные ключи в БД. Последний раз объясняю