On Sat, 20 Sep 2014 20:21:29 +0100
Simon Slavin <slav...@bigfraud.org> wrote:
> > Your suggestion essentially amounts to "names are not
> > decomposable, so keep one version for the user and one for the
> > system."
>
> Sorry, I don't think I got that across effectively. If I make up a
> database that stores names, I'm storing them pretty-much for two main
> reasons: to know the name and to sort by name on displays and
> printouts. So I keep one column for the whole name ("to know the
> name") and one for the name in the order I want to see it sorted ("to
> sort by names"). Two things you need, make two columns. I see no
> reason to split name up into three artificial units.
I think you got your point across just fine. "no reason to split name
up into three artificial units" is the same as "names are not
decomposable".
The units aren't artificial, else the history of Europe would surely
have been different. Names if nothing else have legal meaning. There's
a case in court in Tennessee currently because, in that state, the
couple can't put just any old thing in the "last name" of the birth
certificate.
I can well appreciate that might not matter to your database, which is
really my point. What we're really dealing with here is a question of
problem domain: what does the name *mean* in the context of the
database in question. For you, evidently, it's the string by which its
owner identifies himself. You take what he gives you, and you
reproduce it once for sorting purposes. Because not every database has
such relaxed needs, your advice is not generally applicable.
You say,
> I don't understand why anyone would want to sort on firstname
I guess you've never produced a club membership or other informal
listing by first name. I thought that was pretty common in those clubs
I've heard about over there, with the Chesterfield couches and brandy
and cigars by the fireplace, old chum?
That also suggests you've never had to reconcile two databases in which
the people's names were the only identifying information. Some years
ago a friend of mine integrated 50 separate state databases of doctors
for the AMA. Much hilarity ensued, as I'm sure you can imagine. The
job would surely have been harder if last names hadn't been
identified.
> I suspect that those thousands of databases had their fields defined
> in the 1970s, along with checking to see that all three fields
> weren't blank and didn't have anything but letters in them. And that
> such things would only be done in the US.
Really? HM Revenue and Customs doesn't require you to distinguish
between your given and family names once a year? Your drivers license
doesn't say "Surname" on it anywhere?
> If you want to assess their success, ask yourself how many times
> you've seen NO-MIDDLE-NAME in official records. Or someone who
> apparently has the lastname of OMALLEY. Or someone who apparently
> has a lastname of Al-Haj and is therefore sorted into the 'A's.
These are not necessarily database limitations or database design
issues, as you know. Just because some COBOL system running IMS in
1975 didn't admit nonalphanumeric data, doesn't mean that in 2014 we
can't distinguish last name from first.
> Anyone who worked for a big company these days and created such a
> database should get called in and told to do it again properly.
The day that happens, the lunatics will have been put in charge of the
asylum, because "properly" will have lost all meaning.
I hope we've finally exhausted this topic. Now, if you really want to
usefully direct your righteous outrage, please join me in my petition
to get web payment forms to allow, for the love of God, spaces in
credit card numbers.
--jkl
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
