People with names that break computers

No, I addressed this. It's really simple: you don't need fields for different names!! Just have a single field: "name". That's it. People can put whatever name they want there, using any character set. If they want a "patronym", whatever the hell that is, no problem, just stick it in there! If they want a suffix like a bunch of Southerners here in America insist on for some archaic reason (like "Jimmy Bob Dalton III" or "Joe Smith Jr."), no problem, just put it there.

For mailing addresses, this is all you need. Postal organizations do NOT care about your name, they just want your address and some kind of name as a check in case there's a delivery problem (or there's been a forwarding address filed for a particular name). Payment processors may need something more defined, but those are frequently more standardized by country, but usually, at least here in the US, all they care about is "enter your name as it's written on the card here...". They don't care about your actual name, they just want to match the string you enter with the string the credit card has.

> Sorry, but how can you not have a name? Good luck getting an ID document without a name. That doesn't make sense.

That's what 32-36 are referring to, cases where children aren't given a name for an extended period of time. Even without extreme cases. what about a Hospital system meant to be used to track newborn children? It's necessarily not going to be able to rely on a name, because it's not uncommon for children not to be named for a few days. A system such as that might want to track the children by the mother, date of birth, and birth ordering (in case of twins, triplets, etc).

> This just sounds dumb: Unicode has thousands upon thousands of characters. Only with Chinese can I see this possibly being a problem, but even here I thought Unicode did account for that. Unicode was designed to have every conceivable glyph that every language on Earth uses.

Just because it was designed to accommodate every conceivable symbol, doesn't mean it currently has every conceivable symbol. What about the symbol Prince used for his name[1]? What about a language that's not in Unicode yet?

> There really isn't that much to it: you need to have two strings (and one can be null as I said above)

If someone has a single name, does it go in the first name, or second name spot? Is this enforced, and where?

It's not that you won't generally be served well by your suggestions, it's just that the problem space is complex enough that it's worth thinking about a little before falling back on that. It might be that you don't even need a name, or only need it for billing, and your requirements may change depending on what payment processors expect (is it okay to just save a single string for whatever full name they submit?) These are all worth giving a little thought to up front, because changing the schema after it's in use is always harder, and that goes both ways, Splitting a string into multiple name parts is hard for many of the same reasons listed here.

1: http://parkerhiggins.net/2013/01/writing-the-prince-symbol-i...

Ah, thanks!

> If it's a US government database, then you don't need to worry about stuff like that, because they're not going to care about people using some obscure language that isn't covered by Unicode.

Why, because immigration isn't tracked in US government databases? Liaisons in other countries aren't tracked in US government databases?

> Is there even such a language? I doubt it, not any that are in actual use.

A simple google search shows that yes, there are[1]. They may not be common, but you know where uncommonly used languages see use? In names, from people trying to preserve their heritage.

> Now again, as I mentioned before, a lot of this depends on exactly what your application is

Actually, you're saying that now. I've been saying it from the beginning. Actually, that was the point of my first comment, and the point of my second comment, and the point of this comment. You said "Assuming that you're going to require at least two names (no single-name names allowed), then a string for First Name and a string for Last Name should be sufficient." and I was trying to point out that even if we accept the assumption that you need to require at least two names, there are cases where depending on your purpose you should really examine what you really need an build your schema around that, not some simple rule summarized as two database fields of unlimited length Unicode text.

I said this explicitly in the first comment with "What this really means is, depending on the application and how important the name is to you, you will have different requirements."

The entire last paragraph of my second comment was about this.

> so it's pretty hard to come up with any ideas or rules without knowing this.

Which is my point, and the point of the linked post about names. You need to know your problem domain, and the data you are expected to encounter. It's also not what you stated in your original comment. I'll just assume you were being a bit overly assertive initially, and it's not really the entirety of your stance, because you're making the opposite argument now. We've wasted a lot of time when you could have just said, "Yeah, if name fidelity is important, know your expected data and make plans for special cases if it's important." Which, again, is exactly what I said in my second comment.

1: http://unicode.org/standard/unsupported.html