Names of People
-
The rule is that you use nvarchar to store names in the database. You could also do away with names altogether and just assign everyone a GUID at birth. Problem solved.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013John Simmons / outlaw programmer wrote:
just assign everyone a GUID
After logging in your site:
Hello, 7798eded-dfac-406c-a49b-b031a7d1afc5
This sounds so accomodating.
-
F-ES Sitecore wrote:
Of course I always use "int" to store phone numbers
And ZIP codes! :rolleyes:
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
And ZIP codes! :rolleyes:
Yeah ... never mind that such area codes in other countries tend to have all sorts of alpha numerics in them. And then you get the odd guy wanting to input his phoneword instead of a number ... since that's how he remembers it.
-
Because, once stored in a database, we will need to look up names and the person doing the search is not the person who entered the name. Having rules for names allows us to compare partial names to locate the records for the person we are trying to look up.
__________________ Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now. © 2009, Rex Hammock
First try: Just replace any special character or space with the wildcard character, then use LIKE to compare. Second try: Use SOUNDEX. Third try: Write your own SOUNDEX-like function. I did this with PostgreSQL, when I realized that some foreign names did not compare well. Eventually, though, I got tired of maintaining it, and just used SOUNDEX.
-
There is no point in establishing rules for ASCII names - simply because most systems now use Unicode which allows Chinese, Persian, Hindi, Russian, Japanese, Korean, Thai, ... you get the idea. OK - I agree that name lookup is a problem with non-European names (and even some European style ones) but establishing rules for something that has pretty much been superseded already seems liek a waste of time and effort! :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
In a previous position I seemed to spend most of my time replacing characters that were 'reserved' in the system. It was an absolute nightmare and was the result of some clever so & so deciding to escape certain characters for some reason that was never fully explained. Apostrophes, commas, ampersands, tildes, back slashes, forward slashes. I hate them all!
I may not last forever but the mess I leave behind certainly will.
-
Over at the Kalzumeus Software website, an article was posted Falsehoods Programmers Believe About Names[^] which, in a somewhat tongue-in-cheek manner, describes some of the bad assumptions made about peoples' names that make websites difficult to use.
We, as programmers, have seen the problems with last names (surnames or family names) such as d'Agastino, O'Dell, McDonnell, Rice-Davies, !Mbeki, la Fayette, von Helstien, duBois, Peñia, Dönitz or Null (Yes, that is a real last name! :-D ). Although not as common, similar problems exist with first names, middle names, honorifics, suffixes (Sr., Jr., II, III, et. al.)
Can we, being serious for a whole minute, come up with a set of sensible rules for handling all names of people that can be written in ASCII? — Adding rules for non-ASCII UniCode characters is an exercise best left for the future. Let's keep this to a discussion of rules and, for now, avoid the question of writing code to implement them – that belongs in other forums!
__________________ Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now. © 2009, Rex Hammock
What you are really looking for is a reliable way of uniquely identifying people. Name is good, but not adequate (see above re: J. Smith). I worked for [a well known credit monitoring company] that needed to do this. Add to that the problem that, in some countries with multiple official languages (e.g., Canada), John Doe may be the same person as Jacques Doe. It turns out that you can uniquely identify a person with a very small amount of extra information. For example, with full name, birth date, and current geographic location, you get something like 85% -- the problem here being ethnically common names like John Smith and Juan Gomez. Add a birth_place_ and you approach 100%. Basically, for most databases you need two fields for "name": a "Full Name" string, and a "Sort By" string. Add some software (commercial libraries are available) that takes care of the "John/Juan/Ivan/Jacques" problems, birthdate/place and current geography (zip code/postal code/city) and you can be nearly certain that you have the right person, and you can assign/retrieve a more convenient UID. The rest of the problems (e.g., last name "NULL", punctuation, etc.) are solved with correct programming. If you have trouble with "NULL", you probably have bigger things to worry about (SQL injection hacks).
Freedom? That is a worship word. -- Cloud William The only thing a free man can be forced to do is die.
-
Over at the Kalzumeus Software website, an article was posted Falsehoods Programmers Believe About Names[^] which, in a somewhat tongue-in-cheek manner, describes some of the bad assumptions made about peoples' names that make websites difficult to use.
We, as programmers, have seen the problems with last names (surnames or family names) such as d'Agastino, O'Dell, McDonnell, Rice-Davies, !Mbeki, la Fayette, von Helstien, duBois, Peñia, Dönitz or Null (Yes, that is a real last name! :-D ). Although not as common, similar problems exist with first names, middle names, honorifics, suffixes (Sr., Jr., II, III, et. al.)
Can we, being serious for a whole minute, come up with a set of sensible rules for handling all names of people that can be written in ASCII? — Adding rules for non-ASCII UniCode characters is an exercise best left for the future. Let's keep this to a discussion of rules and, for now, avoid the question of writing code to implement them – that belongs in other forums!
__________________ Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now. © 2009, Rex Hammock
The Irish are born database killers. If we could just convince them to spell their names like O,Donald, then the tech world would be a happier place. There's really no way to cover it all but to have super long name fields, last name optional, escape and encode/decode, and all that mess. Which, of course, makes indexing and searching so much more fun. I think we're probably all in the same boat trying to deal with a livable middle ground while dealing with the occasional edge-case headache.
-
I can't see why should be any problem with any name - the only rule we have in our system, that the name can contain only printable characters...beside it it can be anything from the Unicode range... If a system has problem with names, that's a problem with the developer and not with the name...For instance the name Null. After reading some articles about it, I'm still can't understand how it can be any problem...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Kornfeld Eliyahu Peter wrote:
For instance the name Null. After reading some articles about it, I'm still can't understand how it can be any problem
Try inserting it into a database and then have some fun retrieving it and running queries.
-
Kornfeld Eliyahu Peter wrote:
For instance the name Null. After reading some articles about it, I'm still can't understand how it can be any problem
Try inserting it into a database and then have some fun retrieving it and running queries.
Not the slightest problem there...With the right type (name is a string) 'Null' (any combination of small or capital letters) will never be the same as the SQL NULL or the .NET DBNull or the JavaScript null... In the very basic level even NULL = NULL in SQL (the lowest level to access the data) evaluates to null... So as I stated before - it is the problem of the developer if the system can not handle 'Null' (or other bizarre) as string...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Which doesn't change original question. But that said you want to make something deterministic which cannot be. If the person that first entered the first name as "nine" it is unlikely to help the second person if the actually spelling of the last name is "9" or "mine" (they heard it wrong.) The only real rules - Name cannot start with nor end with spaces - Name cannot consist of nothing but spaces, which is basically same as first rule. - Name must exist. After that work on something much more important like insuring that each person gets a bill every month and that they actually pay it.
jschell wrote:
- Name must exist.
Why? (see originally linked article.)
-
Kornfeld Eliyahu Peter wrote:
After reading some articles about it, I'm still can't understand how it can be any problem...
Spending some time in QA will cure you of that! ;)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Yeah - the issue is not that either your language or your code or your database don't understand the difference between "Null" and NULL - they do - but do you have actual full control over every single line of code in your stack? Really? You use no libraries at all, for anything, including transport? See this stackoverflow question for one example.
-
jschell wrote:
- Name must exist.
Why? (see originally linked article.)
Mark Whybird wrote:
Why?
I doubt that assertion. If a company wants to deal with an individual as a legal entity, then that legal entity must provide their legal name. If a company wants to deal with a person as a non-legal entity then they must decide if they want to deal with the person or not. If they do then the person must have an identifier that people can deal with. Of course in the context of the discussion one can state that if a person refuses to provide a name, regardless of whether one exists or not, and the company requires it then the company should just not do business with that person. That exceptional case would be so rare and so non-economically impactful the company should just take that option.
