2010-02-25 2 views
10

Я недавно обдумывал имена и способ их хранения. Как правило, у человека будет первое, последнее и среднее имя. Если вы хотите быть особенно полным, вы можете добавить поле суффикса, возможно, даже поле заголовка. Поэтому, если кто-то хочет быть «Доктор Джон Q. Общественный III», они могут. Но у человека может быть более одного почетного и более одного суффикса. Если уж на то пошло, тогда могла бы быть и фамилия с переносом. Итак, что, если вы «Доктор Джон Квинт Максимус Public-Doe III Ph.D. MD. RPh.»? Вы могли бы сделать: Стандартный способ хранения имен в базе данных

 
Persons 
    PersonID 
    Prefix 
    FirstName 
    MiddleName 
    LastName 
    Suffix 
PersonHonorifics 
    PHID 
    PersonID 
    Honorific 
PersonNames 
    PANID 
    PersonID 
    NameOrder 
Но тогда это становится медведем, с которым можно работать, и никто в любом случае не использует их.

Есть ли общепринятый «Стандартный способ» для хранения данных имени?

+0

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

+1

Зачем вам когда-либо обрабатывать Honorifics отдельно? Будете ли вы заниматься рыцарскими орденами, где КГ занимает место перед КГБ? –

+3

@ S.Lott Я хотел иметь академическую дискуссию, не зависящую от требований, и это показалось хорошим примером того, где был компромисс. В сценарии, где вы хотели запросить население по определенной комбинации учетных данных (скажем: все MCDBA, которые также являются MCITP), тогда нормализованная версия может быть предпочтительнее «нежелательного поля». –

ответ

4

Я предпочитаю AD naming style

First Name givenName 
Last Name sn 
Initials initials 
Display Name displayName 
Description description 
Office physicalDeliveryOfficeName 
Telephone Number telephoneNumber 
Telephone: Other otherTelephone 
E-Mail mail 
Web Page wWWHomePage 
Web Page: Other url 
+1

+1: Имя, Фамилия (для сортировки) и Отображаемое имя (включая все украшения, которые нравятся людям). И разумно совместимы с другими способами хранения информации о людях. Это то, для чего предназначены LDAP (и AD). –

+15

+1 (для LDAP) для инкапсуляции наиболее необходимых полей стандартным способом, -100 для непоследовательного именования ('givenName',' sn' ... What?) И странных camelCaps ('wWWHomePage'? Серьезно?). –

1

Я бы начал с рассмотрения стандарта vCard; он нуждается в некоторой нормализации.

2

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

Если у вас есть требование хранить все доктору Джону Квинту Максимусу Public-Doe III Ph.D. MD. RPh, тогда вы создаете для этого хранилище. Но до тех пор, пока ваше последнее имя позволяет получить достаточно данных, доктор Максимус может набрать столько или меньше, сколько захочет, чтобы сохранить его имя и названия.

0

Из моего опыта это обычно

  • Название (как FK, связав к таблице названий)
  • Имя, отчество
  • Отчество
  • Фамилия
  • Предыдущая фамилия (при необходимости уловить смену имени для замужних женщин)
  • Суффикс

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

1

Ниже плохая идея (см первый комментарий):

KISS! Освободите себя и просто используйте «FullName» :-) (Если вам это нужно, последним словом в строке является «Фамилия»)

Вы всегда можете использовать: Дорогое «Полное имя».

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

+2

Плохая идея в целом. Да, у вас может быть поле fullname, но оно должно быть построено на отдельных файлах, иначе упорядочение по имени или seraching по lastname означает использование «% Smith%», что означает, что вы можете использовать t index. Я бы никогда не сохранил только полное имя. – HLGEM

+0

Хороший вопрос :-) Я изменил ответ. (Может быть, для некоторых общедоступных веб-приложений это было бы достаточно хорошо - там, где вы применяете YAGNI и даже не собираете Lastname. (Но это был не вопрос). ... – Robert

+1

Не сортировать по «lastname», проблеме –

1

Вы должны создать свой формат хранения вокруг того, как вы ожидаете использовать данные. Если вам нужно знать разницу между первым именем (именами) и фамилией (именами), то для каждой колонки есть столбцы. Аналогичным образом, если вы (или ваш бизнес) заботитесь о суффиксах/префиксах/средних именах и т. Д. ... достаточно, чтобы хотеть использовать их определенным образом (например, рассылать спам всем клиентам, которые являются врачами), тогда для каждой колонки есть столбцы.Но если все, что вам нужно, это идентифицировать их в отчете или в приветствии по электронной почте, тогда рассмотрите более легкий подход: First_names, Last_Names и оставьте его на этом.

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

0

Если вы не имеете дело со специализированной группой пациентов, подобно врачам, где вам может понадобиться хранить все суффиксы таким образом, чтобы их можно было легко искать (мы часто ищем здесь профессиональный суффикс), тогда вы можете хранить их либо в поле lastname или в отдельном поле суффикса (делает поиск всех людей с именем smith более надежным, если суффикс является отдельным полем). но с разделенным запятой списком. То же самое для префиксов. Я бы предположил, что первое имя, фамилия и имя middlename (Помогает различать дубликаты и без подачи, с меньшей вероятностью, чтобы его вставлять, даже если пользователь знает это), как правило, необходимы для правильного поиска и отправки данных. Я также предлагаю вычисленное поле, которое форматирует полное имя так, как вы хотите, чтобы оно отображалось по электронной почте и т. Д.

13

Иногда вы только думаете, что знаете свои требования. В издательском бизнесе есть информационный стандарт ONIX, который использует следующее. Интересно отметить, что имена First и Middle объединяются в одно поле.

  • Названия Перед именами (например: профессор, Высочество принц, г.Санкт)
  • имена перед ключевыми именами (имена и/или средних инициалов - например: Брендан JE)
  • префикса к именам ключей (например: ван, как Людвиг ван Бетховен)
  • Кодовое имя (фамилия)
  • Имена после ключевых имен (например: Ибрагим, как в Анвара Ибрагима)
  • суффикса к именам ключей (например: Jr, III)
  • Quali и почестей-модификации после ключевых имен (например: MB, PhD)
  • Названия после названия (например: герцог Эдинбургский)
+0

Люблю это, потому что он работает на международном уровне. Также найдена ссылка на фактический документ: http://www.editeur.org/93/Release-3.0-Downloads/#Specification – danielson317

+0

Ничего себе, это здорово. один сам. –

Смежные вопросы