Имя Второе Имя Фамилия. Почему не полное имя?

Ответ 1

Держите свои данные в чистоте, как можно!

Как?

Спросите своего пользователя как можно меньше вещей, сколько вам нужно в то время, когда вы спрашиваете.

Как вы храните имя, это не имеет значения. Важно то, что

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

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

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

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

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

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

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

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

Ответ 2

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

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

Вы также можете тривиально искать или сортировать по given_name, или family_name, или что-то еще.

(Примечание. Я использую given_name, family_name и т.д., а не first_name, last_name, потому что разные культуры помещают свои имена в разные порядки.)

Решить эту проблему в общем случае сложно - вот статья, в которой говорится о том, насколько это сложно: Представление имен людей в Дублинском ядре.

Ответ 3

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

• Колин Ангус Маккей
• Жан Мишель Жарр
• Винсент ван Гог
• Пабло Диего Хосе Франсиско де Паула Хуан Непомуцено Мария де лос Ремедиос Чиприано де ла Сантисима Тринидад Руис и Пикассо

Как вы надежно разложите эту лот?

Чтобы узнать больше, см. ложные программисты верят в имена.

Ответ 4

Я смотрел Испанская гражданская война на днях и нашел это исключение для большинства правил:

• Франсиско Паулино Херменэгильдо Теодуло Франко и Багамонда, Сальгадо и Пардо де Андраде
• Отец: Николас Франко и Сальгадо-Арауджо.
• Мать: Мария дель Пилар Бахамонда у Пардо де Андраде

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

Что мы будем использовать для имен?

• Имя на ярлыке адреса почтовой службы
• Приветствие на сайте
• Неформальное имя

В зависимости от того, для чего будут использоваться имена, мы определяем, сколько информации хранить. Возможно, мы разрешаем пользователю вводить все три из них, включая разрывы строк в первом случае (Generalissimo Franco, возможно, захочет, чтобы его полные названия и назначения были перечислены, если он еще не был мертв). Возможно, мы предоставляем First, Middle, Last, Generation в качестве опции и заполняем остальные по умолчанию. Возможно, мы предлагаем другие общие варианты, такие как Фамилия, Имя.

Это в отличие от старого, первого, среднего, последнего, с которым мы работали, прежде чем я начал программировать в COBOL еще в 1975 году и с тех пор "подходил".

Ответ 5

К сожалению, это похоже на вопрос, как лучше всего сохранить номер в базе данных. Это зависит от того, что вы собираетесь с ним делать - иногда вам нужен int, иногда байт, а иногда и поплавок. С именами это зависит от того, какие культуры вы ожидаете от ваших пользователей, от того, что вы планируете делать с именами (будете ли вы использовать эти имена для подключения к другой системе, которая хранит имена как "фамилия, имя"?), и сколько вы можете позволить себе раздражать своих пользователей. Если это внутреннее приложение для управления персоналом, вы, вероятно, можете позволить себе сильно раздражать пользователей и иметь очень структурированную формальную разбивку компонентов имени (есть путь более 3 - не забывайте mr/mrs, jr, III, множественные средние имена, дефисные фамилии и кто знает, что еще, если вы пытаетесь обрабатывать имена из всех культур. Если у вас есть веб-приложение, которое может быть или не нужно пользователям, вы не можете просить их слишком много заботиться.

Ответ 6

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

например. Если вы хотите найти все г-н Ноланс, ваш запрос будет

SELECT Title+' '+FirstName+' '+Surname As FullName  
from table where firstname = 'Mr' and surname ='Nolan'

сделать это с помощью только полных имен будет боль.

Ответ 7

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

Любая попытка навязать что-либо большее, чем "Имя", обречена быть неправильной, по крайней мере, некоторое время, а иногда и очень разочаровывает пользователей. Одиночные имена распространены в Южной Индии, Индонезии и Пакистане (это сотни миллионов людей), а также странных странствий в Великобритании, таких как я.

"Первая, средняя, ​​последняя" вещь очень ориентирована на США. Немногие другие страны так думают об именах. Пожалуйста, прекратите делать это.

Ответ 8

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

Ответ 9

В большинстве случаев он поддерживает письма, содержащие буквы типа "Mr. so-and-so", или поиск/сортировка по фамилии, которая очень распространена.

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

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

Ответ 10

Такие вещи, как ORDER BY firstname или ORDER BY lastname, возможны, когда вы разбиваете имя на несколько полей.

Не так легко сделать, когда вы сбрасываете все имена в одно поле.

Ответ 11

О единственном, о чем я могу думать, это поиск. Немного лучше искать поле, используя [=], а не сказать [как].

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

Но если вам нужно сделать что-то вроде [Дорогой г-н Ачу], возможно, 3-полевый подход будет лучше.

Ответ 12

Просто два поля: "Полное имя" и "Предпочтительное имя" - легко. Поддерживает каждое имя в существовании (до тех пор, пока язык имеет лексические символы... Итак, да, это исключает языки, которые не имеют письменной формы).

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

Ответ 13

Здесь вещь, даже люди не могут получить это право все время, там слишком много данных и слишком много особых случаев. Я могу изменить свое имя сейчас, чтобы быть 20 частями, а средний 13 - моим "первым" именем. Части имен могут содержать любое количество слов, и может быть любое количество частей имен. У некоторых людей только 1 имя (без фамилии). У некоторых людей много средних имен. У некоторых людей есть первые или фамилии, состоящие из нескольких слов. Некоторые люди сначала перечисляют свою фамилию. Некоторые люди идут по их среднему имени. Некоторые люди идут по прозвищам, которые явно не связаны с их именем.

Если вы попытаетесь угадать эти соглашения в ПО, ВЫ БУДЕТЕ НЕИСПРАВНО. Период. Может быть, вы это исправите некоторое время, может быть, даже большую часть времени, но это даже стоит того? По-моему, вы должны хранить имена в качестве одного поля и перестать пытаться быть милыми, используя имена, чтобы обратиться к человеку. Если вам нужна дополнительная информация о имени (например, прозвище), спросите пользователя!

Ответ 14

Нет никакой выгоды, если вам не нужно сортировать или искать по первому, среднему или фамилии.

Ответ 15

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

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

Все зависит от ваших требований. Нет единого хорошего ответа без того окружения, которое, как ожидается, удовлетворит.

Ответ 16

Проблема i18n может быть искателем в любом случае. определенные культуры используют фамилию сначала, и последнее имя, которое поражает идею имени и фамилии, поэтому мы переходим к полям для фамилий и имен. Подождите, в некоторых культурах нет фамилии, или фамилия изменена полом имени.
Мы можем попасть в племенные культуры, где человек переименовывается во взрослую жизнь. "Sitting Bull" детское название было "Прыгающий барсук".
Это скорее скачок, но то, что я показываю, состоит в том, что чем больше полей у вас, тем точнее дизайн. Должно быть хотя бы поле not null 'данное имя' и поле optional 'surname', привязанное к PK, которое является целым числом. Если вышеупомянутые требования соблюдены, поля могут быть добавлены без проблем с разбивкой запросов.

Ответ 17

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

Ответ 18

Некоторые проблемы могут быть решены путем хранения дополнительного столбца, например PreferredName. Мы делаем это в нашей БД, а также сохраняем столбец префикса и столбец суффикса. например "Профессор Генри W Jones Jnr" с предпочтительным названием "Индиана Джонс".

Ответ 19

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

Ответ 20

Гибкость.

например. Если у кого-то была двойная бочечная фамилия и нет среднего имени.

Ответ 21

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

Ответ 22

Вы не можете всегда отделять фамилию от полного имени чисто и надежно, поэтому есть веская причина отделить ее, потому что вам часто нужна фамилия. После этого есть два общих подхода:

• first_name и middle_name; или
• given_names.

(2), возможно, более предпочтительнее, потому что люди иногда имеют больше, чем буксируемые имена, и (1) в этом отношении более негибкие.

Кроме того, другое общее поле является preferred_name (в дополнение к выше).