12 ms·

A) the proposal is crazy. You probably don’t need to know if someone has a patronymn or a kunya or whatever. Base what you store on what you need. B) Storing t

A) the proposal is crazy. You probably don’t need to know if someone has a patronymn or a kunya or whatever. Base what you store on what you need. B) Storing this as normal data would be an intense pain in the ass to use, for no gain in performance or correctness. Use JSONB, this is what it’s for.

lonelappde 7y ago
This comment is culturally insensitive. You are implicitly assuming that your culture's way of expressing names is all that matters
- goto11 7y ago
  Missing the point. If you just have a single "name" field then you can accommodate any culture perfectly.
  - earthboundkid 7y ago
    This fits the 75% use case, but misses things that do come up, like alphabetizing by last name and emails with casual forms of address.
- earthboundkid 7y ago
  Matters for what? A database is a tool to solve a problem, not a timeless repository of deep cultural meaning. If I make a webapp that is only localized in English, display, first, last will let me solve my common problems: I need to say "My account (John Smith)" in the corner (display name), and I want to be able to write emails that say "John, we know you're wondering how company that sold you a pair of pants three years ago is feeling about COVID-19…" (first name) and list articles by author sorted by last name. Those are all common use cases for apps used by English speakers. Now, if I were making an app to do voting in Myanmar, I would need to deal with there not being last names for many Burmese. If I was trying to track Arab speaking terrorists around the world, I'd want a long list of their aliases and kunya in multiple romanizations (I think the CIA used to prefer "UBL" for Osama bin Laden because they called him "Usama"). If I was making a library app, I might want to have the English romanized name plus the Unicode native language name. Tons of possible problem spaces with different solutions. I just think tagging the different name parts for "Gabriel José de la Concordia García Márquez" is going to be overkill for most English language apps because when are you going to look someone up by maternal family name versus of just doing a full text search for "Garcia Marquez".
goto11 7y ago
If you actually need to know such details then it should be stored in normalized form. Say you have a visa database which must be compatible with multiple naming systems from different countries and where no information can be discarded for security or legal reasons. Then you store the data you need in normalized form. Why would you use weird hacks for essential information? And if you don't need all that detail - then you just save the name as a string and discard the metadata. I can't see it would ever make sense to store a name in JSON format inside a relational database. Either the information is important or it isn't.
Mikhail_Edoshin 7y ago
A) In many cases you don't, but if you store data about authors in a bibliographic database then you probably do. And it's just a part of the package: for example, Donald Knuth went as far as to print people names in their native language in addition to English in his books' indices :)

lonelappde 7y ago

This comment is culturally insensitive. You are implicitly assuming that your culture's way of expressing names is all that matters

goto11 7y ago
Missing the point. If you just have a single "name" field then you can accommodate any culture perfectly.
- earthboundkid 7y ago
  This fits the 75% use case, but misses things that do come up, like alphabetizing by last name and emails with casual forms of address.
earthboundkid 7y ago
Matters for what? A database is a tool to solve a problem, not a timeless repository of deep cultural meaning. If I make a webapp that is only localized in English, display, first, last will let me solve my common problems: I need to say "My account (John Smith)" in the corner (display name), and I want to be able to write emails that say "John, we know you're wondering how company that sold you a pair of pants three years ago is feeling about COVID-19…" (first name) and list articles by author sorted by last name. Those are all common use cases for apps used by English speakers. Now, if I were making an app to do voting in Myanmar, I would need to deal with there not being last names for many Burmese. If I was trying to track Arab speaking terrorists around the world, I'd want a long list of their aliases and kunya in multiple romanizations (I think the CIA used to prefer "UBL" for Osama bin Laden because they called him "Usama"). If I was making a library app, I might want to have the English romanized name plus the Unicode native language name. Tons of possible problem spaces with different solutions. I just think tagging the different name parts for "Gabriel José de la Concordia García Márquez" is going to be overkill for most English language apps because when are you going to look someone up by maternal family name versus of just doing a full text search for "Garcia Marquez".

goto11 7y ago

If you actually need to know such details then it should be stored in normalized form. Say you have a visa database which must be compatible with multiple naming systems from different countries and where no information can be discarded for security or legal reasons. Then you store the data you need in normalized form. Why would you use weird hacks for essential information? And if you don't need all that detail - then you just save the name as a string and discard the metadata. I can't see it would ever make sense to store a name in JSON format inside a relational database. Either the information is important or it isn't.

Mikhail_Edoshin 7y ago

A) In many cases you don't, but if you store data about authors in a bibliographic database then you probably do. And it's just a part of the package: for example, Donald Knuth went as far as to print people names in their native language in addition to English in his books' indices :)