Modeling first and lastname separately

Question

Which arguments should someone consider when designing a new system and has to either store the name of a person as one field or separately as first/last name?

Pros for single field:

• Simpler UI
• No ambiguity when trying to enter the name of a person, who has a very long name (often non evident which is the last name / first name..)
• Less complexity when handling titles (e.g. no need for separate field to enter "M.D" or "Dr.")

Pros for split field:

• Personalised communication is possible "Dear Mr X" or "Dear Julie"
• If a consumed web service needs the first / last name separately, it can be provided easily.
• Better choice for any industry with strict identification requirements (e.g. medical, government, etc.)
• Safer choice, as you can always go back to the single field alternative

Do you see any additional argument that is not listed above?

Update: the question is, what additional (=not listed in the question) arguments can be listed for each solution. I think giving opinions instead of possible pros and cons drives the discussion in the wrong way. Each developer has to make his/her decision about this problem, the aim of this question is to assemble a list of non-trivial arguments that can be evaluated if needed.

Answer 1

First name and last name are not useful concepts. Names work differently in different countries. In most Asian countries, the family name is written first, but it is still used for sorting—so you may put it in first name, and sorting will be wrong, or in last name, and display will be. And then there are countries like Iceland where they don't use family names at all, but instead father's given name. So they simply sort by given name.

The terms “given name” and “surname” (or “family name”) are better in this regard, but I would still avoid them unless absolutely necessary (i.e. official documents like passports do have them, so then you need them), because they just make things more complicated.

• Personalised communication is possible "Dear Mr X" or "Dear Julie"

Except you have no idea whether to call given person by their first name, or last name or what. And don't get me started on the languages that have vocative—you can't derive vocative from nominative in general. No, it's better if you simply ask the user what to call them.

• If a consumed web service needs the first / last name separately, it can be provided easily.

If. If you depend on another service, you are locked to their bad choices. It is no advantage for your own designs.

• Better choice for any industry with strict identification requirements (e.g. medical, government, etc.)

No, it is a wrong choice for these. Official documents generally use the terms “given name” and “surname” (or “family name”), which are less ambiguous.

• Safer choice, as you can always go back to the single field alternative

Actually, due to the ambiguity with Asian names, it is not so clear you can.

Answer 2

The only argument that matters is what are the requirements of your system?

Do you need to deal with just one culture? If so, conform to that culture. Otherwise plan for internationalization (as others have pointed out).

Do you need to get data to deal with government forms, healthcare or other legal / system requirements? Follow whatever those dictate. If that means first and last name, do it. If it means something different, do that.

Do you have a requirement for an API with first and last name (or is it reasonably likely, enough to warrant ignoring YAGNI)? Do what makes sense there.

If you need personalized communications, is it reasonable to just ask someone their preferred name and store that?

The requirements of your system should determine what you do. Do what you have to and YAGNI the rest.

Answer 3

I agree with a lot of what @JanHudec said, although I'd like to expand on that a bit:

• You need to know what your real requirements are, but it is easier to combine information than it is to split it apart once it is combined again.
• Sorting will always be a challenge, as the rules can differ across locales and cultures.
• Many cultures don't match yours, which leads to bad assumptions. (This is Jan's biggest point)

Terminology is Important

Terms like given name and surname or family name have semantic meaning, and your database should always reflect the semantics of your data. Terms like first name and last name have positional meaning, usually based on English and American ideas of how names work. Use the proper terminology for the semantics of your data.

How far do you need to break it down?

There are concepts of title (Mr. Dr. Mrs. etc.) or ordinal (Jr., Sr., III, etc.), and even certifications (PhD, MS, PCAM, etc.) which can be important depending on the context and purpose.

Many locales have the concept of multiple family names (paternal and maternal), and some have none. When filling out forms, sometimes people have to make hard choices as to which name to use, for example using the paternal family name for the "surname" in an American form, or coming up with a last name based on the father's name (Janson).

While in America it is common to have one or more middle names, it's often ignored outside of your family.

Sorting

It helps to have a dedicated field for sort name. That way you can disambiguate the rules when you create the record. It also ensures you have the names sorted in the correct order across international boundaries.

Common Practices

Your real requirements dictate how correct you need to be about names. If you are creating a government or banking web site, then you have more requirements for storing and handling names than something informal like Facebook.

Informal Guidelines

• Have one field that describes how the user wants to be known
• Sort and display uses that one name

Semi Formal Guidelines

• Have one field for a nickname, or how the user wants to be addressed
• Have two fields, one for given name and one for surname (surname should be optional)
• Calculate a sorting field based on locale and the given/surname combo
• Use the nickname when addressing the user directly
• Use the formal name when listing people

Formal Guidelines

• These are dictated by existing policies and procedures for the entity you are supporting
• You need as many fields as the maximum number of name parts you will be supporting, named semantically for what they are.
• Include a sorting field that handles the sorting as you would in the semi-formal case
• Display also is usually dictated by existing policies and procedures. You need to familiarize yourself with them.

Answer 4

If you have more than one way to display and/or utilize the name(s), then you'll probably need separate fields. Along with the data entry, you could provide feedback to show the user how it will be utilized. How you combine them, could lead to converting to a single field in the future.

Have some labels that show: Greeting or Display Name: First Name + Last Name Organizing/Sorting: Last Name, First Name

When you're not sure how this will be used in the future, start with split names and then you can combine them into a single field when you realize that's all you really need. It's not that it is difficult to write an algorithm to split up a single name field into first and last name, but you will make a mistake on a few and people really don't like mistakes with their names. With split fields, users can adjust how they enter their name when they see how it is used. Combining them in a permanent single name field is less risky.

Answer 5

Apart from what @JanHudec has pointed out and with which I agree, it's also worth noting that in many countries people have more than one last name, so single last name field might be irrelevant. E.g. in Spain people have two last names, and they use only one or both of them depending on situation.

Besides you shouldn't personalize communications based on your assumptions as in some cultures you may seem to be rude when calling people by their last names and in case of others it might be the opposite.

Also, some cultures put an emphasis on forms like 'Mrs' vs 'Ms', and they may also combine this word with first or last names depending on a particular case.

So I would lean towards a solution where you have a single name field and maybe additional fields that the user fills that hint how to turn to the user - something similar to what many airlines do when you buy a ticket online. This may also solve the problem of how to split the names if you need it for an external web service you've mentioned.

Answer 6

At add even more to what @JanHudec and @KjMag have pointed out, even in cultures/languages very close to English this becomes a problem. Take German for instance. You have the concept of Vornamen, First names, Nachnamen, Last names, and Rufname, the name you are called. Take my father for example, he has 3 first names, on his birth certificate they are listed in the order Christoph Stephan Andreas. And he has one last name. What do you think the name is he is called by?

The correct answer: Andreas. That is his Rufname, in America he puts that as his first name to fit the American template. So you might assume in Germany the last of your first names is the name you are called but then you have my brother: Christoph Sebastian Herbert Maria. (Now I have given away we are Bavarian) Or my sister Christine Gabriele. What do you think are the names that they are called? Sebastian and Christine respectively.

I would third the answers that say one field for a full name. And I would add to that: maybe add another field for a Surname/family name and pose the question: by what name would you be sorted in a list? And then a final field for: how do you want to be addressed?

Answer 7

If one is going for a global application, one would probably model a person's name as an array of strings. For example, consider the president's name in the movie Idiocracy:

• Dwayne Elzondo Mountain Dew Herbert Camacho

That's his full name. The name contains 6 elements in the array. For US culture, the first name is the first element in the array (Dwayne) and the last name is the last element in the array (Camacho). But that is not always the case.

One could apply culture specific rules to determine the "first" name if the first name is actually the last element and so forth depending on how names work in different cultures/locales.

Also, in the US case, we have cases when the last element is not the last name such as:

• Dwayne Elzondo Mountain Dew Herbert Camacho Jr.

So, maybe a name suffix field or one would have to parse the last element looking for known suffixes based on the culture to get the correct last name.

So, your always better off storing the name in one element (The full name) and then applying a "standardization/sanitation" routine against it to parse out the specific elements as needed. A similar strategy exists for addresses. They are usually collected as one string and then sent to a service to parse the parts.