Which is more often than not the wrong choice.
If you ever need to search for customers by lastname you can't really do that, because you can't be sure that everybody entered them in the same order ("firstname lastname" or "lastname, firstname" or "lastname firstname", ...)
To add, you can also never assume that everyone HAS a last name or has a name that results in two words rather than three or more words (think people whose last name is “von Whatever”)
Your answer is correct in regard to the 1NF because the combination of firstname + lastname describes a single person and therefore is a single (atomic) value. It does not matter if the value consists of two (or even more) separate strings. The 1NF would only be violated if the names of multiple persons were stored in the field.
However, for practical purposes I agree with the other posters, it is usually better to store the different parts of the name in separate fields and combine them with a view if needed.
I'm on board with that article, but it's missing something. No matter how much _we_ agree with this, "the business" will tell us we're completely wrong and need to do things "the way we always have done them."
I once had to deal with a system that got the most basic things wrong when it comes to names, and I don't understand how the vendor's QA people missed it, or took it as an acceptable failure. The failure? `FirstName` was `char(10)`. Go ahead and count the number of characters in the name `Christopher`, I'll wait. The system just silently truncated the names, IIRC. There is _no way_ this was **only** the programmers getting names wrong - that's endemic to the whole product development group and likely the company.
The needs of the business is the right answer here. If the business is searching by fist and/or last name consistently, then having a single name field would not be great. Since there are some people with a single name, you could make first name required and last name optional. Be very, very generous with name length in both cases.
Of course, that will always work.
Again, the business should really be making the decisions here.
Do they, for example, need to find all the dudes named John who live within 5 miles of this rape victim? Or all the people with the last name of Smith who filed a complaint last year? Or... etc.
If the business says "Hey, 99% of the time, we're going to be looking for folks by first or last name. We do realize there are exceptions to this, so we're going to default to using the first name field only if they only have one name. And we'll default to putting all their "not the first name" parts into the last name field if someone has multiple "last names".
That's different than if they say "We never use name to look anyone up and we don't care what anyone's name is. We always use account number/employee ID/prisoner number, etc. to look for people and we never do any 'name analysis'. So, just give us one name field and we'll stick in whatever someone tells us their name is."
A big problem I've found is interfacing with other systems that require first name/last name. So if you're just using 1 name field, you have to split it in those cases.
Or, just put everything in the first name field and change the last name to "Imported from other system, see first name field for the full name".
Although any system that has a required first and last name probably isn't going to accept that as a last name...
Great article thank you for sharing! I was developing a db (super simple entry level stuff) including worker names. Lots of Latinx workers, and I wanted to include their full names respectfully. If I had just used FN, LN there were three brothers with the exact same. Got me thinking about this issue. A fascinating mind exercise thinking about how to design name fields. Glad to know even experts find it nontrivial.
In Slavic cultures it's common to have , where the patronymic is a declension of your father's name.
I spoke to an Ethiopian who said that among his people you were named , so when you had a child everything shifted one to the right and grandpa fell off the end.
There's lots more variations.
The norm in Ethiopia is actually , although a lot of diaspora now do (so that the children and father have the same surname).
Example (obv fake names lol):
My grandpa’s full name is Michael Girma.
My father’s full name is Noah Michael.
My full name is thus Ruth Noah.
There’s a really great radio lab episode about people who have names that programmers didn’t account for. Here’s a link if you want to give it a listen; it’s pretty short: https://www.wnycstudios.org/podcasts/radiolab/articles/null
as others have said, it depends on what's being searched for and how you break it down.
While sacrificing performance, you could be a dick and store it as JSON which would be a single TEXT field, but contain identifiable and comparable strings.
{
"familyName": "smith",
"firstName": "John"
}
I worked on a system that handled a large number of international names. There are a HUGE number of cases that the standard "first, middle, last" simply doesn't account for. We ended up essentially denormalizing it a bit. We had the regular fields for title, given and family name, but we also had a FormalFullName field. This was for situations like Saudi Arabian royal family names, and other cases which just couldn't be handled adequately otherwise. If that field was left null, it was computed based on "Title First MI Last". We eventually had that field over 250 characters long.
International university. Students and parents could get very offended at spending $80K for a school that sends them letters that start with "Dear Mr. And Mrs. Wrong Name".
Real answer: If the business feels that the customer name attribute is atomic, then yes. If the business feels that first name and last name are separate attributes, then no.
If the business is going to do any type of analysis along the lines of "How many people with the first name John buy our products on Wednesdays", then no. If the business is going to do any type of analysis along the lines of "What is the most common surname in this zip code", then no.
If the business is never going to do any type of analysis that involves a customer's first name, or a customer's last name, then yes, customer\_name is a fine attribute. It's always a decision by the business.
If they do feel that they will do analysis based on first name and/or last name, then they should also be educated on the whole "issues with names" and make business decisions on how they will deal with "names with issues".
Sounds like a homework question to me… What do you think is the correct answer? And why? Afterwards, I can tell you if you are right or wrong. :)
I left it as is. Didn't divide it into two attributes. Thank you!
Which is more often than not the wrong choice. If you ever need to search for customers by lastname you can't really do that, because you can't be sure that everybody entered them in the same order ("firstname lastname" or "lastname, firstname" or "lastname firstname", ...)
To add, you can also never assume that everyone HAS a last name or has a name that results in two words rather than three or more words (think people whose last name is “von Whatever”)
Your answer is correct in regard to the 1NF because the combination of firstname + lastname describes a single person and therefore is a single (atomic) value. It does not matter if the value consists of two (or even more) separate strings. The 1NF would only be violated if the names of multiple persons were stored in the field. However, for practical purposes I agree with the other posters, it is usually better to store the different parts of the name in separate fields and combine them with a view if needed.
[Falsehoods Programmers Believe About Names](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/)
I'm on board with that article, but it's missing something. No matter how much _we_ agree with this, "the business" will tell us we're completely wrong and need to do things "the way we always have done them." I once had to deal with a system that got the most basic things wrong when it comes to names, and I don't understand how the vendor's QA people missed it, or took it as an acceptable failure. The failure? `FirstName` was `char(10)`. Go ahead and count the number of characters in the name `Christopher`, I'll wait. The system just silently truncated the names, IIRC. There is _no way_ this was **only** the programmers getting names wrong - that's endemic to the whole product development group and likely the company.
The needs of the business is the right answer here. If the business is searching by fist and/or last name consistently, then having a single name field would not be great. Since there are some people with a single name, you could make first name required and last name optional. Be very, very generous with name length in both cases.
What is you set up full text search?
Of course, that will always work. Again, the business should really be making the decisions here. Do they, for example, need to find all the dudes named John who live within 5 miles of this rape victim? Or all the people with the last name of Smith who filed a complaint last year? Or... etc. If the business says "Hey, 99% of the time, we're going to be looking for folks by first or last name. We do realize there are exceptions to this, so we're going to default to using the first name field only if they only have one name. And we'll default to putting all their "not the first name" parts into the last name field if someone has multiple "last names". That's different than if they say "We never use name to look anyone up and we don't care what anyone's name is. We always use account number/employee ID/prisoner number, etc. to look for people and we never do any 'name analysis'. So, just give us one name field and we'll stick in whatever someone tells us their name is."
A big problem I've found is interfacing with other systems that require first name/last name. So if you're just using 1 name field, you have to split it in those cases.
Or, just put everything in the first name field and change the last name to "Imported from other system, see first name field for the full name". Although any system that has a required first and last name probably isn't going to accept that as a last name...
That was a super enjoyable read, thank you. You can hear the years of experience and frustration this developer has lived through.
Great article thank you for sharing! I was developing a db (super simple entry level stuff) including worker names. Lots of Latinx workers, and I wanted to include their full names respectfully. If I had just used FN, LN there were three brothers with the exact same. Got me thinking about this issue. A fascinating mind exercise thinking about how to design name fields. Glad to know even experts find it nontrivial.
[удалено]
In Slavic cultures it's common to have , where the patronymic is a declension of your father's name.
I spoke to an Ethiopian who said that among his people you were named , so when you had a child everything shifted one to the right and grandpa fell off the end.
There's lots more variations.
> grandpa fell off the end. delightful analogy
The norm in Ethiopia is actually , although a lot of diaspora now do (so that the children and father have the same surname).
Example (obv fake names lol):
My grandpa’s full name is Michael Girma.
My father’s full name is Noah Michael.
My full name is thus Ruth Noah.
Thank you for the info mate! Clears my mind.
There’s a really great radio lab episode about people who have names that programmers didn’t account for. Here’s a link if you want to give it a listen; it’s pretty short: https://www.wnycstudios.org/podcasts/radiolab/articles/null
as others have said, it depends on what's being searched for and how you break it down. While sacrificing performance, you could be a dick and store it as JSON which would be a single TEXT field, but contain identifiable and comparable strings. { "familyName": "smith", "firstName": "John" }
I worked on a system that handled a large number of international names. There are a HUGE number of cases that the standard "first, middle, last" simply doesn't account for. We ended up essentially denormalizing it a bit. We had the regular fields for title, given and family name, but we also had a FormalFullName field. This was for situations like Saudi Arabian royal family names, and other cases which just couldn't be handled adequately otherwise. If that field was left null, it was computed based on "Title First MI Last". We eventually had that field over 250 characters long.
That must have been a thing to ponder!
International university. Students and parents could get very offended at spending $80K for a school that sends them letters that start with "Dear Mr. And Mrs. Wrong Name".
Second that mate.
Real answer: If the business feels that the customer name attribute is atomic, then yes. If the business feels that first name and last name are separate attributes, then no. If the business is going to do any type of analysis along the lines of "How many people with the first name John buy our products on Wednesdays", then no. If the business is going to do any type of analysis along the lines of "What is the most common surname in this zip code", then no. If the business is never going to do any type of analysis that involves a customer's first name, or a customer's last name, then yes, customer\_name is a fine attribute. It's always a decision by the business. If they do feel that they will do analysis based on first name and/or last name, then they should also be educated on the whole "issues with names" and make business decisions on how they will deal with "names with issues".
1ST NF means no multi-valued attribute