Как смоделировать более одной «фамилии»?

В испаноязычных странах мы используем более одной фамилии, например:

Имя ↘ ↙ Фамилия
                Педро Артуро Родригес Лойола
        Отчество ↗ ↖ (?)

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

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

Q: Как рассчитывает DBA?

A: 0, 1, много

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

ContactId
NamePart {"Джон", "Смит", ...}
NameType {название, имя, семья, ???}
Заказ {1, 2, 3, ...}

Для Pedro Arturo Rodríguez Loyola(контакт № 1) у вас будет четыре строки:

1 / Педро / дано / 1
1 / Артуро / дано / 2
1 / Родригес / семья / 3
1 / Лойола / семья / 4

Таким образом, он не ограничен какой-либо конкретной структурой, но все же имеет смысл для данного контакта там. Что вы делаете, когда у вас есть кто-то с 3 или 4 именем или фамилией? или девичья фамилия?

Обратите внимание, что я изменил порядок по сравнению с предыдущей версией этого ответа - порядок представляет собой порядок по всему имени, а не просто порядок в типе имени, потому что в некоторых культурах фамилия стоит на первом месте, возможно, вы разделены заглавные части "Сэр Джон Смит II".

Дополнительное Чтение

• Программисты лжи верят в имена
• Две фамилии

Это может помочь. Пост юмористический, но проницательный.

[Имя] [Фамилия] не является универсальным правилом для имен. Это просто обычное место, где вы живете. Если вы навязываете правила, рано или поздно у вас появятся люди, которых нельзя добавить в вашу систему.

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

Я хотел бы пойти с чем-то вроде этого:

• Отображаемое имя (для непротиворечивых имен при отображении форм / данных): (должно быть [первое] [последнее]).
• Другие имена / полное имя (для поиска, более точного соответствия и т. Д.). Здесь пользователь может написать что угодно, вплоть до заданной длины; длина должна быть больше, чем вы думаете, должно быть достаточно разумно - например, если вы считаете, что 40 символов должно быть достаточно, поставьте 500 :)).
• Адресация (Mr, Mrs, Ms, Jr, Sr, -san, пользовательское значение (например, Tov.) И т. Д.).
• внутренний идентификатор (этот идентификатор должен однозначно идентифицировать каждого человека в вашем приложении, предотвращая конфликты имен).

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

Несколько интересных примеров имен и ссылок:

http://en.wikipedia.org/wiki/Nicholas_Barbon

http://en.wikipedia.org/wiki/Prince_%28musician%29

http://en.wikipedia.org/wiki/P_diddy

http://en.wikipedia.org/wiki/Burmese_name

Это не сложная вещь ..... или я что-то упускаю.

Есть эти поля: name(varchar), lastname(varchar).

Затем форма для заполнения полного имени, например: Jorge Patricioи фамилия Pèrez Gonzáles.

В поиске у вас есть много операторов сравнения, например, в MySQL, например, likeкоторые помогут вам искать.

В основном составленные фамилии всегда в порядке. Pérez Gonzálezв основном так говорит фамилия, а не в обратном порядке.

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

Существует три типа личных имен: полиномы (имена с несколькими компонентами), мононимы (имена только с одним компонентом, например, «Cher») и пиктонимы (имена, представленные изображениями, например, The Artist ).

Человек может иметь несколько имен, играя роли , например, Юридическое имя и Предпочтительное имя.

Полином имеет несколько компонентов, из которых должны быть указаны имя и фамилия. Есть несколько видов фамилий:

1. Регулярные фамилии (Джонс)
2. Двуствольные фамилии («Вон Уильямс» или «Луи-Дрейфус»)
3. Фамилии True Compound {имя: фамилия "Хуан Пабло": "Фернандес де Кальдерон", фамилия: "Гарсия Иглесиас"}

3 важно, потому что ожидается, что его будут называть г-ном Фернандесом де Кальдероном , а не г-ном Фернандесом де Кальдероном Гарсия-Иглесиасом.

Таким образом, в основном, есть обязательное поле фамилии, и вторичное поле вторичной фамилии.

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

Скорее всего, ваша система заботится только о четырех «именах» кого-то:

1. Display Name , которое позволяет им знать , что они вошли в систему.
2. Неофициальное название , по которому вы бы обратиться к ним по телефону.
3. Официальное название , с которым вы бы обращаться к ним по переписке.
4. Сортировка Имя , которое выражает # 2 таким образом , что это будет упорядоченным в списке.

Многие системы просто используют чье-то формальное имя для № 1 и № 2, оставляя единственные имена, которые вас интересуют, как «строку, представляющую имя пользователя» и «строку, представляющую, как следует сортировать первые».

С точки зрения моделирования данных, определите только те значения, которые вам действительно нужны. Как лучше всего оптимизировать хранение этих значений - это деталь реализации, которую вы будете вызывать только в случае чрезмерной оптимизации. (Конечно, вы «могли бы» просто сохранить имя и фамилию, но что бы вы сделали для человека, у которого только одно имя?)

Давайте рассмотрим это по-другому.

Ваша система должна подключаться к другим системам, не важно, насколько вы гибки, если они нет. Итак, что делают системы, с которыми вы должны передавать данные?

Когда я звоню своему врачу на прием, они спрашивают меня о моей дате рождения, затем системы показывают им список людей, которые соответствуют, затем они спрашивают меня о моем имени, и, наконец, спрашивают мой адрес, чтобы подтвердить, что они выбрали правильный человек.

Врач должен знать имя, по которому я обращаюсь при разговоре; им также нужно знать имя, чтобы написать письмо, если они напишут мне.

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