4 ms·

What's the proper solution here? Just a "name" field? Maybe formal_name and informal_name so you can do things like "Howdy ${informal_name}" without awkwardly

by mulmen 5y ago

What's the proper solution here? Just a "name" field? Maybe formal_name and informal_name so you can do things like "Howdy ${informal_name}" without awkwardly using a last name? 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?

xena 5y ago
Author here, yes it's intended to reduce month/day ambiguity.
- mulmen 5y ago
  Cool, thanks. It worked but I have never seen the format before. Any reason for not using a standard format? Just creative license?
  - xena 5y ago
    Creative license mostly. No real reason otherwise!
    - noizejoy 5y ago
      I’m using yyyy-mm-dd for pretty much everything, since it also conveniently sorts by time when used in file names and other alphabetic sorting systems :-)
- deleted 5y ago
  [deleted]
adoxyz 5y ago
I think full_name or just name would be sufficient. And optionally allow given_name, middle_name, family_name if you really need it/want it for some purpose. But for a lot of common use cases, there's really no need to separate first and last name in a database imo.
- oogetyboogety 5y ago
  These names follow with schema.org attributes. https://schema.org/givenName https://schema.org/givenName ( first ) https://schema.org/additionalName https://schema.org/additionalName ( middle or alias ) https://schema.org/familyName https://schema.org/familyName ( last )
- sokoloff 5y ago
  I’ve had to have a name field and a sortable name field before: Name: The Who, Sort_Name: Who
davidw 5y ago
Just use a 'name' field if possible, yes. 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.
- mulmen 5y ago
  Contacts is an interesting use case. I prefer to have my parents full names in the contact but also have a display name set so texts from my mom say "Mom". So even in the case of "traditional" names there's still a use case for more than just first and last.
jdougan 5y ago
There isn't a "proper" solution that handles everything because just when you have text nailed down, someone decides their name is a novel pictogram (Prince) or an odor (no one yet, but if the iSmell was still being manufactured...). 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.
pjscott 5y ago
As far as I know, almost all practical cases can be dealt with by storing family name (which must be optional), given name, and locale. Or just store a name as arbitrary Unicode text, if you don’t need to do anything fancy.
noizejoy 5y ago
Nickname is another related mechanism that allows for a single name field.
Mawr 5y ago
> 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? 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.
- xena 5y ago
  The dark truth is that it was inspired from the iOS Lojban locale date format. I'm not sure where they got that from, Lojban doesn't define a date format.
chmod600 5y ago
My name is the SHA1 hash of the UTF-8 representation of the next 30 unicode code points that follow it. 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?
- mulmen 5y ago
  How do you respond without knowing the following content?
  - jdougan 5y ago
    Drop in a future/promise and backfill. Or just generate 30 nulls.
eyelidlessness 5y ago
I think the proper solution is probably going to vary a lot depending on use case. Just full_name is probably a good default. 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).
mjevans 5y ago
Ask rather than trying to be 'smart' and out-think the end user. 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.
- Orou 5y ago
  Anyone who's had to parse free-text international addresses can tell you that this is terrible advice. People type things into computers incorrectly all day long. We prompt users to select things like country from dropdowns with good reason. Imagine having to delete user data for GDPR compliance and needing to determine which of your 1,000,000 users are in the EU from a free-text field. Oh, this user wrote "Czechia" instead of "Czech Republic"? What do you mean they wrote the name with accents? Oh they wrote the name in their native language and not English? Have fun parsing all this: https://en.wikipedia.org/wiki/List_of_country_names_in_various_languages_(A%E2%80%93C) https://en.wikipedia.org/wiki/List_of_country_names_in_vario...
  - wolfgang42 5y ago
    The parent did say “targeted to a country you do [understand]”. The impression I get is that for most address handling the only thing that’s critical to have structured is the country; probably everything else should be free-text until you have a reason not to[1], at which point you should find someone who deals with them for a living (probably a third-party provider), and even then it's probably best to provide a fallback for the weird edge cases. [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!

by mulmen 5y ago

xena 5y ago

Author here, yes it's intended to reduce month/day ambiguity.

mulmen 5y ago
Cool, thanks. It worked but I have never seen the format before. Any reason for not using a standard format? Just creative license?
- xena 5y ago
  Creative license mostly. No real reason otherwise!
  - noizejoy 5y ago
    I’m using yyyy-mm-dd for pretty much everything, since it also conveniently sorts by time when used in file names and other alphabetic sorting systems :-)
deleted 5y ago
[deleted]

adoxyz 5y ago

I think full_name or just name would be sufficient. And optionally allow given_name, middle_name, family_name if you really need it/want it for some purpose. But for a lot of common use cases, there's really no need to separate first and last name in a database imo.

oogetyboogety 5y ago
These names follow with schema.org attributes. https://schema.org/givenName https://schema.org/givenName ( first ) https://schema.org/additionalName https://schema.org/additionalName ( middle or alias ) https://schema.org/familyName https://schema.org/familyName ( last )
sokoloff 5y ago
I’ve had to have a name field and a sortable name field before: Name: The Who, Sort_Name: Who

davidw 5y ago

Just use a 'name' field if possible, yes. 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.

mulmen 5y ago
Contacts is an interesting use case. I prefer to have my parents full names in the contact but also have a display name set so texts from my mom say "Mom". So even in the case of "traditional" names there's still a use case for more than just first and last.

jdougan 5y ago

There isn't a "proper" solution that handles everything because just when you have text nailed down, someone decides their name is a novel pictogram (Prince) or an odor (no one yet, but if the iSmell was still being manufactured...). 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.

pjscott 5y ago

As far as I know, almost all practical cases can be dealt with by storing family name (which must be optional), given name, and locale. Or just store a name as arbitrary Unicode text, if you don’t need to do anything fancy.

noizejoy 5y ago

Nickname is another related mechanism that allows for a single name field.

Mawr 5y ago

> 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? 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.

xena 5y ago
The dark truth is that it was inspired from the iOS Lojban locale date format. I'm not sure where they got that from, Lojban doesn't define a date format.

chmod600 5y ago

My name is the SHA1 hash of the UTF-8 representation of the next 30 unicode code points that follow it. 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?

mulmen 5y ago
How do you respond without knowing the following content?
- jdougan 5y ago
  Drop in a future/promise and backfill. Or just generate 30 nulls.

eyelidlessness 5y ago

I think the proper solution is probably going to vary a lot depending on use case. Just full_name is probably a good default. 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).

mjevans 5y ago

Ask rather than trying to be 'smart' and out-think the end user. 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.

Orou 5y ago
Anyone who's had to parse free-text international addresses can tell you that this is terrible advice. People type things into computers incorrectly all day long. We prompt users to select things like country from dropdowns with good reason. Imagine having to delete user data for GDPR compliance and needing to determine which of your 1,000,000 users are in the EU from a free-text field. Oh, this user wrote "Czechia" instead of "Czech Republic"? What do you mean they wrote the name with accents? Oh they wrote the name in their native language and not English? Have fun parsing all this: https://en.wikipedia.org/wiki/List_of_country_names_in_various_languages_(A%E2%80%93C) https://en.wikipedia.org/wiki/List_of_country_names_in_vario...
- wolfgang42 5y ago
  The parent did say “targeted to a country you do [understand]”. The impression I get is that for most address handling the only thing that’s critical to have structured is the country; probably everything else should be free-text until you have a reason not to[1], at which point you should find someone who deals with them for a living (probably a third-party provider), and even then it's probably best to provide a fallback for the weird edge cases. [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!