meta: What is the purpose of the M01 10 2022 date format? Is that intended to reduce ambiguity between the month and day? Why not an ISO 8601? Why isn't it M01 D10 Y2022?
Reconsidering whether you actually need to store a name, or whether you need more than an “informal” name is another good default. I’ve scare quoted “informal” because what you probably mean is somewhere between “preferred conversational” and “legally identifying”, and people may prefer to use a name they’ve chosen in formal settings (my understanding of Xe’s article suggests xer do [and sorry if I’m misrepresenting that, or misusing xer]). I have used a chosen name (originally chosen by a friend) for almost 20 years, both in formal and informal contexts. And many many people do, even from childhood (eg choosing to go by a middle name or a specific variant of the name on, say, their birth certificate).
If for whatever reason you need or have a good reason to ask for/store a “formal” name and a “preferred conversational” name, those are probably reasonable default names, though you may want to also allow for multiple “conversational” names, and without qualification that can get ambiguous very quickly (which loops back to “reconsider” IMO).
It is an instance of a general problem that policy can be anything, even stuff that is inconsistent. Closest I've ever got was in an object DB where I could define various subclasses of a Name class that were related to the Person instances (along with titles and whatnot). There were obvious efficiency and UI issues. Harder to do with relational.
Most of the other replys talk about 'Legal' names vs various levels of friendly name.
How about Mailing Address fields for snail mail? Don't decompose it, just have a full text area and store EXACTLY what the user provides. POSSIBLY toss it at a an address validation routine your postal services. Be prepared to handle an 'International' printed label where you might print a blob of text you don't understand, targeted to a country you do, and require manual processing for country, payment, and customs forms validations outside of the typical flow.
Try to show the end user examples of where and how the information will be typically used.
Never, ever, break down components of user provided input; at least not without letting them confirm if they're correct and allowing them to skip it if it isn't.
https://en.wikipedia.org/wiki/List_of_country_names_in_vario...
[1]: One good reason is that, as you say, people get things wrong—even their own address—on a regular basis, and you may be charged more money if you’re e.g. shipping things with the wrong postal code for the rest of the address. But even then it’s good to provide a workaround if necessary; post office databases can be wrong too!
I've never seen that before, it's hilarious. As to why, imagine you're from a country that uses a subpar date formatting like MM DD YYYY, and while you're conscious enough to notice its badness and improve on it slightly by adding an "M", you're not conscious enough to search for a fundamentally different approach - a sane date format. A local maxima of sorts.
Otherwise, add a whole bundle of fields and make none of them mandatory. That's what Google Contacts does, and that seems to work ok.
But for a lot of common use cases, there's really no need to separate first and last name in a database imo.
Name: The Who, Sort_Name: Who
If you don't have 30 more code points worth of stuff to say, you can feed fewer bytes into the hash. But then you can never speak about me again.
What's the database schema for that?