Нет у меня никакого первого имени

Так вы и до транслитерации по ISO 9 доберётесь: IVAN IVANOVIČ.

Разработчики не всегда задумываются, а точно ли им нужно хранить компоненты имени? Какова цель? Будут ли эти компоненты использоваться по отдельности?

Трудно предугадать. Можно как угодно правильно делать в пределах своей системы, но однажды прилетит интеграция с чужой апихой, где будут поля first и last. И вот ты достаёшь свой тупой ржавый .split(' ') и кромсаешь им чьи-то имена как попало. Это гораздо хуже, чем вкрапления чужой культуры в какие-то там имена полей.

У нас всё по фэншую :) surname, name и patronymic, упомянутый в статье.

На самом деле, проблема несколько высосана из пальца. Кому какая разница, как в потрохах системы в таблицах называются конкретно эти поля.

Больше режет глаз, когда натыкаешься на поля типа raschetniy_schet - вот это да, проблема.

Если в вашем проекте не предполагается заполнение официальных документов или почтовых адресов, не проще ли хранить имя пользователя в виде одной opaque-строки?

Не проще.

То, что оно не предполагается сейчас - совершенно не означает, что оно не понадобится в дальнейшем. Поэтому лучше сразу хранить данные в нормальном виде, а не валить всё в строку. Потом разгрести будет сложнее.

А ещё - в строку оно будет свалено криво. Один оператор будет начинать с фамилии, другой с имени, а третий вообще забьет инициалы.

Больная тема. Даже если брать только коренных граждан РФ, то есть народы, у которых патронимы отсутствуют.

Ранее у адыгов были патронимы, но не было фамилий. Примерно, как у исландских племен. А у калмыков система патронимов была гораздо сложнее принятой сейчас.

Но административный ресурс всё порешал. До поры - до времени. Пока Жерар Депардьё и Стивен Сигал не стали россиянами. А отчествами так и не обзавелись. Зато у Сигала есть второе имя - Фредерик. Но оно нигде в российских документах не отображается.

Так что, какая разница, как что называть? Как не назови - все равно найдутся исключения.

не проще ли хранить имя пользователя в виде одной opaque-строки

Если у вас в базе лежит "Александр Сергеевич Пушкин" одной строкой, тогда поиск по фамилии в SQL придется делать через LIKE, что сильно просадит скорость выполнения запроса на большой базе.

Называть столбцы надо так, чтобы было понятно ИИ

Мне кажется ваша статья - это пример "лучшее враг хорошего".

Да, first name, last name и middle name не идеальны - но имхо они самые общеупотребительные.
Это как "рогоз" или "мультифора". Не всегда "лучшее" и "правильное" - лучше, так как может вызывать больше вопросов и сложности понимания.

В их (Google) Identity Platform я вообще не вижу компонентов имени, зато есть displayName и screenName

Я с вероятностью 99% уверен, что Гугл разбивает ФИО отдельно. Я думаю просто для фронтового API когда это не нужно они сливают в displayName.

Но вот я смотрю в стандарт OpenID, который повсеместно используется в настоящее время

Given name, middle name, Family name - еще норм и понятно
Но, First name, middle name, Surname - понятнее имхо

patronymic, matronymic - имхо ужас. Как вы назовете это поле? patronymic_or_matronymic? Если patronymic - то туда можно вводить matronymic? и тд и тп

не проще ли хранить имя пользователя в виде одной opaque-строки

Если вы хотите не-расширяемый API и из-за бесполезного перфекционизма огрести проблем в будущем, то пожалуйста!
А в реальности, делать нужно с точностью наоборот: хранить раздельно, а в API возвращать в виде одной opaque-строки если клиентам не нужно раздельно. И API легко меняется без backward-compatibility-changes если нужно его расширить.

Боюсь представить, как бы отреагировал автор на поля first_parent и second_parent ;)

First, middle и last адаптируются под любую культуру, и это более или менее общепринято. У нас middle это отчество, во многих странах - второе личное имя. У нас last это фамилия, в Исландии - отчество. Если для нашей предметной области действительно важны различия между этими ситуациями, тогда надо городить сложную структуру данных, где для каждой части имени есть какой-то name_part_type, список которых мы ведём отдельно. В большинстве же случаев достаточно first/middle/last, и даже если мы не знаем, что именно в эти поля пишут жители какой-нибудь экзотической народности - можно не волноваться, наверняка они делают это каким-то общепринятым способом.

можно заглянуть в собственный заграничный паспорт

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

В разных случаях называем по-разному: как привычно заказчику, как уже есть в коробке (которую берем за основу), как придумал архитектор, как есть в соседней системе, с которой нужно обмениваться данными, в общем, единой схемы нет.

Основные проблемы, с которыми сталкивался, были вызваны не тем, что в разных системах эти атрибуты названы по-своему, а другими вещами:

1. Одновременно с тремя отдельными атрибутами (first_name, last_name, middle_name) существует еще и атрибут full_name, причем пользователи (или клиенты в широком смысле) могут непосредственно менять как отдельные атрибуты, так и сборный.

2. Есть ошибки в написании (какой-нибудь midle_name поди еще запомни).

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

familiya, imya, otchestvo

Мы используем: name , surname , patronymic

И я видел как кто-то использовал у себя в API: `i`, `f`, `o`

в русской традиции фамилия, имя и отчество не имеют фиксированной позиции: Илья Ильич Обломов и Обломов Илья Ильич — оба варианта правильные

ФИО — это канцелярская форма. И скорее даже атавизм раннего бумажного документооборота.

А в русской традиции позиция фиксированная: Имя Отчество Фамилия. Если полистать классическую литературу, то ваш пример будет иметь вид:

Обломов, Илья Ильич

Потому что фамилии, как правило, достаточно для идентификации, особенно если добавляется "титул" (граф, профессор, доктор, лейтенант), а имя с отчеством — уточнение, отделяющееся запятой.

Если смотреть на стандарты, то можно взять W3C RDF vCard: https://www.w3.org/2006/vcard/ns-2006.html#Name
Там familyName и givenName

Если у тебя две системы где firs_name и last_name, и отчество либо отдельно куда-то либо вместе с именем
А потом делаешь новую систему, которая будет интегрирована с первыми двумя

то лучше уж firs_name, last_name, middle_name чем что-то другое

Интересно, что бы и где бы в анкете написала

Екатери́на II Алексе́евна, Екатери́на Вели́кая, урождённая Софи́я Авгу́ста Фредери́ка А́нгальт-Це́рбстская

?

В Латинской Америке часто помимо имени папы еще и имя мамы отдельно указывается

Автор не последователен. Если уж не нравится грязнобуржуйские неймы, то зачем вообще называть эти сущности на не родном для славянского уха языке?

Вот абсолютно валидный js код, например:

var имя = 'Петр'
var фамилия = 'Иванов'
console.log(`${имя} ${фамилия}`)

Всё, проблема решена.

Мои знакомые испанцы-португальцы с четырьмя именами нервно смеются в сторонке :)

"Клаудио Тобиас Перейра Мартинез" и всё в таком духе.

Структуру нужно выбирать под задачу и здесь обычно формат понятен из требований. Например, имя и фамилия по отдельности могут интересовать в контексте поиска, сортировки или заполнения типовых форм. Для отчества с сортировкой ни разу не сталкивался.

В остальных случаях, когда нет понятных ограничений, лучше использовать opaque строки. У меня в адресной книге есть такие персонажи как "Mike холодильник", "Support", "k20-35", "Тамара шлагбаум" и т.п. и спасибо разработчикам, что не лезут с советами как правильно.

Статья о том, как найти себе проблем. Поиск всех Ивановых в базе усложняется кратно. А еще имеем винегрет из «Ивановых Иванов» и «Иванов Ивановых». И на закуску имеем в базе «Абу Абиб» и «Абу Абиб». Только первый написал имя и фамилию, а второй фамилию и имя. А еще прикольно бывает имена до инициалов сокращать, или фамилии, как в банках. И тут тоже хотелось бы как-то выбрать, что есть что.

А терминология - главное чтоб описана была, а last_name или surname уже не оч важно.

Как мне кажется, стоит выбирать представление имени в зависимости от способа его использования, которых, грубо говоря, три - и они не обязательно исключают друг друга:

• ответ на вопрос "как вас называть?". Это просто непрозрачная строка, опционально - отдельно полный и сокращённый вариант. В идеале, никогда не должен заменяться другими перечисленными вариантами или генерироваться из них. К примеру, не очень хорошо составлять его из паспортных ФИО.

• интеграции с другими системами. Тут нужно смотреть, что требует эта система. Государства и документооборот я тоже включаю сюда - к примеру, для РФ это будут три "паспортных" поля: имя, фамилия, и необязательное отчество. А если нужна интеграция с несколькими системами, у которых слишком сильно отличаются ожидания от имен, то нужно несколько вариантов имени - к примеру, для другого государства может потребоваться другой набор полей.

• способ отличить одного человека от другого. Это во многих системах работает не очень хорошо - слишком много потенциальных коллизий, к примеру. Но в обиходе используется часто, поэтому для каких-то систем имеет смысл. Это представление будет зависеть, в первую очередь, от ожиданий и желаний пользователей/операторов системы. К примеру, в школьном электронном журнале для этого могут использовать пару "фамилия, имя". Другой пример - в телефонной книжке я ожидаю возможность ввести "Иван дрова", чтобы отличить его от "Иван работа 2" - и при этом ожидаю отдельного поля (или полей) для полных имён этих Иванов.

Ну, если прямо вот хотите, то вот Вам ONIX: https://www.editeur.org/93/Release-3.0-Downloads/#Specifications -> Contributor тэг

Там

Personal Contributor Names
A personal contributor name consists of eight (8) distinct data elements:
• Title(s) before name(s) or prefx(es) to entire name(s)
• Name(s) before key name(s) (includes given names as appropriate)
• Prefx to key name(s)
• Key name(s) (usually the family name)
• Name(s) after key name(s) (including given names where appropriate)
• Suffx after key name(s)
• Qualifcations and honors after name(s)
• Titles after name(s)

наслаждайтесь, но не убейтесь )

User identifier: upload custom json (10mb max)

Как только с GovTech или FinTech работаешь, такая проблема отпадает сама собой. Потому что банк сказал вот так вот у них по бумажкам должно быть! И бюрократия им вторит. И тут внезапно оказывается, что абстрактные first & last names своим пересечением как раз покрывают требования почти всегда.

Но общей атмосфера небольшой идиотии это не отменяет, да :)

Ага. Делаешь last name, а потом выходишь на испанский рынок, а там primero apellido и segundo apellido :-D та-дам! А потом идешь на бразильский, где может быть до 10-ти given names и столько же surnames. А на французском и нидерландском рынках тебя ждет nobiliary particle типа "chris de burgh" или "jean claude van damme" и вот ты уже чешешь репу, как сортировать этих достопочтенных д'Артаньянов по букве А. Ну и добиваем ситуацию Исландией, где вообще нет фамилий как таковых...

Проверил в гугл переводчике, он уверенно переводит last_name как фамилия. Так что не особо проблема, так же как и с first name

Conspiracy theory below:

США странна иммигрантов, к примеру у меня везде в документах FN/LN. Работая здесь с людьми я понял что положить все имена по полям редко просто не возможно. К примеру у меня есть человек в команде из Индии у которого его имя и фамилия и что то там еще это 5 слов разделенных пробелом, пойди найди столько полей.

Так что поступили я пологаю логически, решая простую проблему. вот у вас есть одно поле, проблема с ним одна и человеческая, не понятно как быстро идентифицировать. По этому поле разделили на первую часть и последнюю часть, предполагая что вся ваша шибурха типа Иван Иванович 3 будет частью first_name, а last name будет просто Иванов (всегда одно слово). По этому при звонке вас попросят last name и DOB(или какой нибудь номерок) чтобы идентифицировать.

Еще колонка в БД "has_penis" должна быть, это ближе к российской традиции, да и никакого iso не припомню на этот счет.

Начать стоит с того, а нужны ли вам имена-то вообще?

Как-то все забыли, что есть степени. А они часть имени: профессор, доктор, во многих странах.

Если говорить о России, то есть такие междометья перед отчеством: Оглы. Фарук Оглы Фатехович Ибн Аругат.

Это тоже часть данных в паспорте РФ.

Испаноязычные страны: как правило 2 имени и 2 фамилии, причем фамилии не семейные и у всех членов разные (дети наследуют от отца и матери).

Причем, для остальных человек может представиться любым из своих имён, которое ему больше по душе.

Так что хорошую универсальную модель, к сожалению, определить невозможно.

Ну вот, допустим, у меня интеграция с API Почты России. И им нужны все 3 поля. Васяну они посылку не отдадут. И если не заставить пользователя заполнить эти 3 поля в разных физически разделенных инпутах, он же, сволочь такая, напишет именно Васян, а потом будет винить меня, что ему посылку не отдают.

Ради интереса посмотрел как в базе моей конторы хранится имя пользователя — там один строковый `p_fio` 🗿. Мы уже попали в смешную ситуацию когда потребовалось в одном из наших сервисов выводить только имя пользователя вместо полного имени. Сам столбец может быть заполнен абсолютно произвольно, отсюда мы получили комментарии от "Михайлович", "Иванов", "C" и т.п. Исправить это можно примерно никак.

Уникальным идентификатором польователя у нас является логин, с которым связан другой мем. Ссылки на одно и то же значение в разных таблицах могут иметь имена: customer, customer_id, owner, accound_id и моё любимое — cust_login 🤡 Учитывая специфику нашей системы, где многое приходится делать руками (сырой SQL да), поиск по юзерам это особый вид приключений.

Стоит добавить, что здесь речь не просто о столбцах в БД, а о именах полей (свойств) доменной модели. Поэтому, как они называются - вопрос действительно важный.

Очень здорово, что вы проанализировали стандарты. Опираясь на них, можно действительно пересмотреть подход к наименованию этих свойств.

Но из вашего же анализа я вижу, что единого мнения на этот счёт нет, а значит "здесь так принято" всё ещё имеет власть

Да без разницы что и как называть. Необходимо только чтобы все и везде в пределах проекта называли что-то одно одинаково. Эванс в своей известной книге по DDD для этого вводит такое понятие как "ubiquitous language". И я вообще считаю, что глоссарий проекта всегда должен быть обязательной частью его wiki.