I single string field, for how they want to be addressed. If the system requires a legal name then two string fields, the legal name, and the preferred name to be addressed by.

Based on the comments here, I would say it can't be done. So just use a single name field, and don't use the name field for unique identification.

Also no expert, but I require first name with almost no validation. Surname/last name optional.

I'm hardly a professional but what's the big issue with just having a string field for the name. Why separate first last middle suffixes etc. Seems entirely pointless. When you want to search for someone you can just search for a substring instead of a particular field.

Did I just win database?

Two fields.

First, Legal Name, as required to appear on legal forms in their area. (And oftentimes if they don't fill this in correctly it'll then be on them, and not on you.)

Second, Preferred Name, so that you can throw that into greetings and whatever else you feel the need to personalise.

Even a “legal name” can be different things in the same legal jurisdiction, or not be a concept that really exists at all. I’m in the USA and my birth certificate doesn’t have distinct first, middle, and last name fields. It’s just a single line with my whole name typed out.

That's sort of my point. The Legal Name field is a single field, like it apparently is on your birth certificate. It's just a byte-stuffer identifier filled with something that can be used by the business for any legal forms that come up.

The individual parts inside don't, and shouldn't, matter.

Also, long-standing common law precedent in the US is that people can call themselves whatever they like for any reason at any time as long as it's not with intent to deceive or defraud. This is the basic principle behind, for example, businesses run using stage or pen names (see: "Prince").

Even stranger is that birth certificates are the foundation for all identity in the United States, yet there are >14,000 forms and very poor standards around them.

Well, the number of middle initials/names that I used in the past is dependent on the constraints of the particular system, so I have no possible way to be consistent going forward. I would rather not use any at all, but Social Security and credit cards have one, while my credit union has the other, the DMV and my birth certificate have both, and I use neither when it doesn't seem important. It's definitely unreasonable to use my full legal name for everything, so I think at least three would be needed.

So long as the business gets something that they can use as a legal identifier, they don't need to care about what is inside it.

The whole problem of people not having middle or family names goes away when it's treated as a single field. You don't care about tokenizing the field, because you only ever reproduce that field verbatim.

If the user believes a middle name identifier isn't necessary, then it probably isn't. It's only one aspect of the identifiable information used to identify the legal entity of that person anyway. If you have a name, address, possibly CC information, and email, that's probably more than enough to claim they're a customer for whatever legal purpose the business needs.

The problem here is that you might need more than one "name" like string. One goes into the address of an envelope, but if the letter starts with "Dear" or "Hello", then what follows is usually a different name.

And you can't extract any piece of the "envelope" name to give you the "hello" name: For a person named John Smith, in some cultures it's normal to say "hello John", in others it's "hello Mr. Smith", in still others it's "hello Smith".

And of course, the full name could be "John Smith" or "Smith John" depending on culture. And then there are cultures that have more than one "word" to a name, but there is no family name.

One solution to the "hello name" would be to ask for it separately. Every time you're tempted to parse or rearrange a name, just don't, and ask the user instead, and make a new column or field to put it in. Now that's a paradigm that might stand a chance of winning database. Although ironically your correct rendering of everyone's name will doubtless create mismatches with all the officially sanctioned incorrect renderings by other inferior mortals out there.

For all correspondence with a business, I don't need a "Hello Fred" or "Dear Fred" or "Dear Mr Fred Example".

They should stop with the BS and just state my name:

Fred Example,

Congratulations! You have won a lifetime supply of...

Right. For each purpose, add a new field and ask the user.

I wonder how many fields would be the end result. I have no idea.

Seems like even in the most varied case there wouldn't be more than about three: full legal name, brief-but-formal name such as Mrs. Smith or Dr. Jones or Lawrence, and informal name such as Larry.

Things that come to mind offhand:

- First initial and last name are used for some things, such as usernames.

- First name and last initial are used for some things, such as public displays where you don't want to have the full name

- Last name is used to sort lists

- Names are entered differently due to error or constraints in different places, so you want a way to search the parts that stay the same. Sure, you can imagine everybody just had a string field, but it can't happen all at once. And on a global scale, there are definitely people who will enter their name differently anyway.

The listed reasons for separate fields contains assumptions that may not always be be accurate.

How do you tell an initial from a single character name?

How do you sort by last name if a person has one word for their entire name?

Assuming names are spelt the same or have a fixed length is also not accurate.

It’s all a trap - using one string might be a terrible solution, but it might also be best.

How do these usernames / public displays work for people without two names? When you sort by "last name" do you really mean "surname"? Are you going to add more fields for searching and sorting keys, so when 鈴木一朗 comes along you can search by "イチロー" or "SUZUKI" or 4 or 5 other reasonable search terms, and where is he going to be sorted?

It sounds like you're just kicking the problem downstream a tiny bit, and making it slightly worse by adding another point which enforces an invalid data model.

Your last sentence is certainly true but I don't see how separate fields makes it any better (or worse).

There are people who only have one name, so anything that relies on having two names is essentially broken.

You commonly see companies with user names that started as first character of first name + last name, and then you see later ones that don't follow the pattern when they realize they can't make it work.

> There are people who only have one name

My wife for one. At the very least make the last name field optional.

One point in favor of the separate fields is that users in general suck at computer input.[0] So we have a user entering her name into our website. And then we need to compare that against some database into which she entered her name five years ago. If we have one freeform field, then we have to deal with small inconsistencies that may or may not be significant.

Say the user has three given names and a family name. For whatever reason, she puts double spaces surrounding the two middle names, but she didn't last time. Or jams them together, maybe with another punctuation. Are those semantically meaningful differences? Do the spaces indicate we have two separate people? Would a shortened form for one of the names be meaningful? Or if she misspells the abbreviation for "Marquise"; is that part of her name now? Etc.

If we're accepting that names can have infinitely varied forms, and that whatever the user enters right now is canonical, then questions like that become very difficult. Normalization for comparison is a real requirement in some cases, and separate name fields give us a leg up on that.

I'm not saying this is insurmountable, or that we should make it the user's problem. Just that the single field doesn't quite solve everything in one fell swoop.

---

[0]:I don't say this to blame the users -- computers overall could almost certainly do more to not leak the details of storage into the front end where users have to deal with it.

> Say the user has three given names and a family name. For whatever reason, she puts double spaces surrounding the two middle names, but she didn't last time. Or jams them together, maybe with another punctuation. Are those semantically meaningful differences? Do the spaces indicate we have two separate people? Would a shortened form for one of the names be meaningful? Or if she misspells the abbreviation for "Marquise"; is that part of her name now? Etc.

Why do you care, though?

As I said, because we need to compare it to other entries.

Names can be extraordinarily long or just a single char. Theres a lot of stories where serious issues are caused by software systems and their implementation of handling names.

To answer your question: I dont know if theres a good single spec to follow.

Length is such a problem. Growing up, I knew a girl whose last name was DiMichaelangelo. It couldn’t even fit on a Scantron for tests.