37

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.

Community
  • 1
Istvan Devai
  • 495
  • 1
  • 4
  • 7
  • 11
    What are you trying to do with those names? Do you have legal requirements? Is there any consequence other than *display* for the user's name? – Darkhogg Aug 01 '17 at 11:03
  • 1
    I would implement two single field names: one field for display name and one field for sort name. – mouviciel Aug 01 '17 at 12:25
  • @Darkhogg let me turn the question around: what legal requirements can lead to a split firstname/lastname decision? One I've mentioned in my question about ("industry with strict identification requirements eg medical") – Istvan Devai Aug 01 '17 at 12:53
  • 1
    @mouviciel How does this help compared to first/last name? Could you mention any major Saas application that is doing it in this way, so we can look at an example? – Istvan Devai Aug 01 '17 at 12:55
  • Read the answers to see how it helps. iTunes does this. – mouviciel Aug 01 '17 at 13:35
  • 9
    Firstname/lastname distiction does not support people with only a single name like "Cher". – JacquesB Aug 01 '17 at 13:37
  • 78
    I advise you to read the following article: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ it's a real eye opener when thinking about names. – Pieter B Aug 01 '17 at 13:57
  • @JacquesB wow good point :) https://en.wikipedia.org/wiki/List_of_legally_mononymous_people – Istvan Devai Aug 01 '17 at 14:18
  • 2
    Also, royalty typically only have first names. Do you really want a scathing review written by a prince, queen or emperor because they couldn't sign up for your service? – JacquesB Aug 01 '17 at 14:44
  • 10
    You might consider asking this question on [ux.se], the community there might be able to offer a different perspective on this essentially user interface problem. – 11684 Aug 01 '17 at 15:04
  • 9
    @PieterB Some of the points in that article are questionable and sometimes you have to make assumptions to get things done. That article doesn't provide useful advice on how to handle names. If a name contains non-unicode characters, what do you do, allow the user to upload a picture? What if there are non-visual aspects - allow a video with sound? What if a name is performance art and can only be performed at midnight in Hong Kong? At some point you have to get real and get on to solving problems instead of revelling in theoretical corner cases that your user base will never encounter. – Reinstate Monica Aug 01 '17 at 15:15
  • Passport data pages for various countries: https://commons.wikimedia.org/wiki/Category:Passport_data_pages – Istvan Devai Aug 01 '17 at 15:20
  • 1
    When you make a report, are you going to sort on `lastname, firstname` or on `firstname lastname`. If you don't separate them you don't have a choice, you can only sort them *as they were typed in*, which I promise you will not always be the way that you expect. – RBarryYoung Aug 01 '17 at 17:08
  • 2
    Microsoft programs, which I would imagine are localized in far more languages than most of us deal with, have a name and surname, and reading field for both. Similar restraints apply for air travel and passports. I don't think it's a realistic scenario that you'll run into people who can't handle breaking the name up into these somehow. – Casey Aug 01 '17 at 21:16
  • 2
    This applies to your question pretty directly https://www.w3.org/International/questions/qa-personal-names –  Aug 01 '17 at 21:26
  • 5
    @Solomonoff'sSecret programming starts with questions. After reading that article I hope you have a few more questions and write better software. Regarding names without unicode characters: now you've at least made the conscious decision: "we're not going to support that". The list isn't a: "you have to support this" list. It's so you can make a decision whether or not to support some things. – Pieter B Aug 02 '17 at 06:46
  • 1
    @SGR I think you are reading the article wrong. The things he mentions are not things your have to absolutely support. They're things you need to have knowledge of. Then make a risk/reward assesment. And then decide what to support and what not. Also, Mc'Donalds was very unimpressed that he couldn't put in his name into the name field or use his name as email. If 99.9% support is enough for you, then go for it, but at least you now made an informed choice. 99.9% is not enough for a company like google. – Pieter B Aug 02 '17 at 11:33
  • Note that some cultures have name formats like [familyname] [givenname(s)] [lastname]. *Family name* is also a part that's inherited, so is the *last name*. Standard practice is to abandon the family name if there are only firstname/lastname fields. – sampathsris Aug 02 '17 at 14:29
  • 2
    On the kalzumeus article, it's also a good trigger for writing a correct error message. Many forms insist that the email address I enter is not valid because it contains a +, while all evidence points to the contrary. Instead of telling the user their name is wrong, tell them you didn't recognise the input or something like that. – Cronax Aug 02 '17 at 14:49
  • @cpburnz, Apparently I did not... Now it has 76 upvotes (including mine) ;) – Roland Tepp Aug 07 '17 at 09:39
  • I don’t have a middle name. I have two first names. And I can legally use any one, or both in any order. Have fun. – gnasher729 Mar 26 '21 at 15:42

7 Answers7

55

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.

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
  • 2
    If the app is used in different parts of the world, the field labels would need to be localized along with how they're combined/used. – JeffO Aug 01 '17 at 11:43
  • 5
    @JeffO, the real issue is that these days you are rather likely to have people from different countries in the same system, so you need to create a system and find a way how to insert names from different cultures into it so it works reasonably consistently. Don't enter that rabbit hole unless you really need it. – Jan Hudec Aug 01 '17 at 12:17
  • @JanHudec: Thank you for your input. First/last vs given name/surname: interesting point.. althgouh I don't see what difference this makes. Usually people treat surname as a synonym of last name, so I don't see how this helps reducing ambiguity when entering names. (Merriam-Webster also uses these two as synonyms). – Istvan Devai Aug 01 '17 at 13:21
  • 1
    @JanHudec Personalised communication: I guess your main point here is "even if you have the name split up, you cannot use it due to practical difficulties", and I have to somewhat agree, although it is pretty common to see the "Dear Mr X" type of salutation in emails or printouts. – Istvan Devai Aug 01 '17 at 13:22
  • @JanHudec "Web service consumption" I don't see your point here, because your starting point is "split names are bad", therefore it makes your system bad as well. I guess we can all agree, that at least for some systems, split names make sense (eg passport handling, birth certificates, etc.) Therefore, I don't think labeling it bad is a good starting point, rather it is just something to consider. – Istvan Devai Aug 01 '17 at 13:22
  • @JanHudec "industry with strict identification requirements": my argument here was, that it is better to use split names in case of the named industries, not how we actually split them up. – Istvan Devai Aug 01 '17 at 13:23
  • @IstvanDevai, no, split names are not that bad. First name and last name is bad. That *is* a difference. Split names are still a can of worms though. A *big* one. Don't open it unless you actually need to. – Jan Hudec Aug 01 '17 at 13:24
  • @JanHudec "ambiguity with Asian names, this is not so clear you can" good point that the order of concatenation matters and is country specific. – Istvan Devai Aug 01 '17 at 13:39
  • @JanHudec The question is exactly about why is it (if at all) a can of worms? The point about first/last name being ambiguous to users from countries where the first/last convention is reversed is a good one! Anything else? – Istvan Devai Aug 01 '17 at 13:53
  • 1
    About the asian situation, I once was faced with this issue where we tried to adapt an application made for the North-American market to China. The Split names caused issue because they wanted the whole name field to be just one field as this is what they usually see. Presenting was easy, but parsing and splitting proved to be problematic. That is the Surname ? the first character ?, works in most cases but not always so how to split the string from a unique field into split name fields ?... we just ended up using surname for the chinese version. – Newtopian Aug 01 '17 at 14:44
  • 1
    I wish I could wave a magic wand and strike the notion of "middle name" from everyone's mind so they stop telling me they need a field for it. It should be banished from all user interfaces. –  Aug 01 '17 at 21:11
  • 4
    @IstvanDevai there was a legal case in California where a contract was declared void because credit laws required "last name". The person had a dual Hispanic surname, but when asked for last name, the first (paternal) surname was given, which is common. The other party lost their collection case because the name on the contract was not his "last" name, i.e. the one at the end of his full name. An example of how first/last invites confusion, and is not entirely synonymous with given names/family names. –  Aug 01 '17 at 21:22
  • 1
    @hatchet I don't think that makes a lot of sense. If you're writing an application to be used by English speakers, you may well want to be able to distinguish between "Mary Ann's contacts" and "Fred's contacts." I get a lot of correspondence that starts with things like "Hi Casey J.!" which were probably not intended to look like they were machine-generated but obviously are. – Casey Aug 01 '17 at 22:13
  • 7
    @Casey - middle names should be included in given names field, because that's what they are: secondary given names. If I had a dollar for everytime I've seen a Hispanic person who has no middle name, but a dual surname get their first (and most important) surname shoved in a middle name field, I'd be retired already. If you want to know what to call a person, have a field for that, separate from name. Then Bartholomew Frank Edward Smith Wellington can tell you to call them Bart. We may speak English, but there are people here from non-English speaking places, and their names get entered too. –  Aug 01 '17 at 23:01
  • 1
    @hatchet I see your point, but that design has disadvantages too -- after all, you're asking someone to type in a first name twice in a lot of cases. I don't think having a middle name field is necessarily bad, especially if you're developing more or less exclusively for American users. – Casey Aug 02 '17 at 02:34
  • 1
    @Casey, just pre-fill the “call name” with the first part of the full name. It will work for those people who are called by their first name and the rest has to fill it either way. – Jan Hudec Aug 02 '17 at 07:18
  • 4
    -1. While the answer itself is not totally wrong, it does not make much sense for the question at hand. The OP looks for more arguments for either using either one field or two fields for human names. Whether it is called "first/last" or "given/sur" is not the focus, it's just the labels the OP had in mind. All other points seem highly opinionated to me, and in my personal experience with creating and deploying applications for large customers, the assumptions of the OP are completely normal and just *do happen* that way. This answer just tries to argue the parameters of the question away. – AnoE Aug 02 '17 at 11:44
  • 1
    In Android, there is a "sorting name" field that allows the user to override the default sorting. I've found that useful several times with Japanese names, when the Kanji could be read either way. – Simon Richter Aug 02 '17 at 17:42
32

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.

Becuzz
  • 4,815
  • 1
  • 21
  • 27
  • 9
    There is no such thing as "one culture" any more. Even the smallest communities have mixed cultural norms and languages. – BobDalgleish Aug 01 '17 at 15:22
  • 7
    @BobDalgleish True, but sometimes it doesn't matter. Sometimes the cost of supporting multiple cultures makes the business people just say no. – Becuzz Aug 01 '17 at 15:30
  • So, if you only pick one culture, which one would it be? The business people will have to decide how many people they want to offend. It is, ultimately, up to the programmer to know that it is not a trivial problem, and that it requires real decisions with real consequences. – BobDalgleish Aug 01 '17 at 19:52
  • 1
    @BobDalgleish It is up to us to know that it isn't a trivial problem. And it is our job to make sure the business people know that. But if they choose to ignore it entirely or are more concerned about other things (like time to market, etc) and would rather come back to it later, that is up to them. If we can give them good alternatives, we can minimize the pain. But unless we are the ones making the final call on the requirements and how many people we are going to inconvenience / confuse, we are going to have to defer to those who have that responsibility. – Becuzz Aug 01 '17 at 20:01
  • 9
    @BobDalgleish Presumably whichever culture is dominant in the market for which the application is being developed? I don't think this is actually that mysterious or rare. – Casey Aug 01 '17 at 20:16
  • 3
    @BobDalgleish - "culture" is irrelevant. No one asks about your culture when you are issued documents. If I needed to support only Serbia (where I'm at the moment) I would include first and last name as those are defined on every document issued in this country, and that's it. It doesn't matter what your culture is. Your passport, drivers licence etc will have first and last name, period. – Davor Ždralo Aug 02 '17 at 10:37
  • 1
    @BobDalgleish, but there absolutely is "one culture" in some highly relevant areas where software is developed. For example, one of my larger customers has hundreds, if not thousands of legacy applications, everyone of which assumes persons to have names stored in two fields. Sure, I can tell them that my application only uses one field and denies hacking them apart, but then I can also just look for a new job... – AnoE Aug 02 '17 at 11:47
  • If all your name requirements are dictated by management, and you never have to work with legacy applications, vendor applications, or newer systems or technologies, then, of course, you can limit your design. Since you never have anyone in your country that sues because you cannot spell their name correctly, it must make your life a lot easier. – BobDalgleish Aug 02 '17 at 14:13
  • "What are the requirements of your system?" is the type of response that causes issues for many people when logging into a site. Having a limit on length is always going to be wrong? Excluding characters will also be wrong? There are thousands of reasons the requirements will be wrong. – icirellik Aug 02 '17 at 14:29
  • 2
    @icirellik Wrong in what way? Are those things (length limits, etc.) wrong if you are trying to perfectly model the universe? Certainly. But I have never been asked to perfectly model the universe and every possible way someone could want to pick a name. Do I account for Klingon names? No. But why not? Someone might do that someday (honestly wouldn't surprise me if someone did that now). But there comes a point at which you just know there will be some things that just won't work with your model. And the extra dev time to handle every possibility just isn't worth it. (cont...) – Becuzz Aug 02 '17 at 15:01
  • 1
    @icirellik (...cont) Sometimes you just have to make a choice as to what you are willing to miss out on. I seriously doubt there is any system on this earth that can properly handle every naming convention. There will always be something that doesn't work. See my [favorite list about name assumptions](http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/). Something, somewhere just won't jive with what you want to do. And unless you are building an application for storing and using every name ever, it probably isn't critical to cover every possibility. (cont...) – Becuzz Aug 02 '17 at 15:01
  • 1
    @icirellik (...cont) There comes a point at which practicality beats out correctness. – Becuzz Aug 02 '17 at 15:02
  • 1
    That all depends on perspective and usage. From the perspective of a user that is willing to give you money, they will likely move on. From the perspective of the company, they were never worth the investment. As for usages, it depends on the application. An application to guarantee health care to all Americans cannot be pragmatic, it must work. A social webapp that tracks your calories has more leniency and the cost of correctness likely outweighs the benefits. – icirellik Aug 02 '17 at 15:14
  • @icirellik Exactly. As you said "It depends on the application". – Becuzz Aug 02 '17 at 15:18
8

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.
Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
5

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
4

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.

KjMag
  • 187
  • 10
  • 1
    Presumably if you are actually localizing you can use a different template for different languages – Casey Aug 01 '17 at 18:19
4

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?

Hangman4358
  • 367
  • 2
  • 7
  • 1
    "Last name" is just another name for "surname," not literally the word that appears last in sequence. The last name of Nakayama Taro is "Nakayama." – Casey Aug 01 '17 at 18:21
  • 2
    To add another case: My grandfather was called "Antoon Leendert van Ingen Schenau" => given name(s): "Antoon Leendert"; called: "Leen"; family name: "van Ingen Schenau" to be sorted under "Ingen". Neither the calling-name, nor the correct sorting can be derived easily from a first-name/last-name entry. – Bart van Ingen Schenau Aug 02 '17 at 08:37
  • 1
    @Casey according to who? in japan it is "upper name", for instance, not "last name". – eis Aug 02 '17 at 08:42
  • 1
    @eis In Japan it is 名字. But here in the English-speaking world, "last name" is a synonym for "surname" and not literally "the last word in someone's sequence of names." – Casey Aug 02 '17 at 10:12
  • @eis For substantiation you can refer to this dictionary definition: http://www.dictionary.com/browse/last-name?r=75&src=ref&ch=dic – Casey Aug 02 '17 at 10:19
  • Yes, but that's just the English-speaking world. It wasn't claimed that this database design should apply only to that. – eis Aug 02 '17 at 11:22
  • 1
    @eis I'm not sure what point you want to make. The users won't know the difference if you call the database field last_name instead of surname; one is just a synonym of the other. If your concern is presenting the software to non-English speakers, then it's irrelevant because both "surname" and "last name" are English terms and you should use the term in whatever language you mean to localize the page into. If the concern is you want people who don't know English to be able to use the English page, well, that seems like a pretty half-hearted way to address the actual problem. – Casey Aug 02 '17 at 13:23
  • "english-speaking world" is usually used to refer to countries where english is the native language. English is used in software development in lot of other countries as well. Just because "english-speaking world" consists of countries that usually have last name == surname, that doesn't mean all software developed in english is developed in that context or that kind of culture. – eis Aug 02 '17 at 14:51
  • 1
    @eis OK, well, that is not what I meant. What I meant is that "last name" is an English term that invariably refers to a surname. Here is another reference to make my point http://ejje.weblio.jp/content/%E5%90%8D%E5%AD%97 – Casey Aug 02 '17 at 15:43
-2

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.

Jon Raynor
  • 10,905
  • 29
  • 47
  • 3
    Single field and then "parsing" is a really bad idea. Consider a person whose surname is "Senior": how do you parse that? What about "de la Jolla" as a surname? – BobDalgleish Aug 01 '17 at 15:21
  • I mentioned parsing or a name Suffix field. If a generic solution is needed one would need a name parser so you could handle the each case like "Senior" and "de la Jolla". One could use AI and train it how to recognize names. I bet if one fed it a large enough data set it would be able to recognize the "de la Jollas" of the world. But that is one possible solution. Certainly collecting discrete parts is possible as well but that has it's downsides. – Jon Raynor Aug 01 '17 at 15:59