Try to understand these issues or rather how they could affect your business processes and software implementations down the line rather than dismissing them on a technical level.
You can store the Unicode representation just as you normally would. But what you don't do is assume that your Unicode representation is the only representation of the actual name.
More concretely, there are names that have multiple equally valid ways of writing them. You can probably expect that usually the same one is used, but you should absolutely not require this when building your business processes.
Even more concretely, as an example there are transliteration or simplification / shortening rules that allow people with otherwise strange or long names to buy an airline ticket. The actual, real name may not be any of the ones you have in your system. This matters e.g. when searching for someone or in customer support.
As for people without names (or unknown names), you should probably recognize that the handling might differ by country. E.g. records with "John Doe" in the US might have to be handled differently: analogous to "NULL != NULL" in SQL John Doe != John Doe. Or maybe even "Jane Doe == John Doe" in some cases. See also "Fnu Lu" (First Name Unknown, Last Name Unknown) used in the US.
And although I don't have knowledge about all the countries in the world, it may very well be that this leads to situations where the "no name" has to be handled specially or at least understood to be a special case, completely differently from other cases.
Try to understand these issues or rather how they could affect your business processes and software implementations down the line rather than dismissing them on a technical level.
You can store the Unicode representation just as you normally would. But what you don't do is assume that your Unicode representation is the only representation of the actual name.
More concretely, there are names that have multiple equally valid ways of writing them. You can probably expect that usually the same one is used, but you should absolutely not require this when building your business processes.
Even more concretely, as an example there are transliteration or simplification / shortening rules that allow people with otherwise strange or long names to buy an airline ticket. The actual, real name may not be any of the ones you have in your system. This matters e.g. when searching for someone or in customer support.
As for people without names (or unknown names), you should probably recognize that the handling might differ by country. E.g. records with "John Doe" in the US might have to be handled differently: analogous to "NULL != NULL" in SQL John Doe != John Doe. Or maybe even "Jane Doe == John Doe" in some cases. See also "Fnu Lu" (First Name Unknown, Last Name Unknown) used in the US.
And although I don't have knowledge about all the countries in the world, it may very well be that this leads to situations where the "no name" has to be handled specially or at least understood to be a special case, completely differently from other cases.