Editorial on Ellison, McNealy, and national ID card
Thu, 25 Oct 2001 10:54:56 -0700
> _But they don't have different primary keys._ This is what the "Fight
> the big DB!" camp doesn't get. There doesn't need to be a big DB,
> there just needs to be a lot of little DBs that use the same GUID.
> The real question is "What do we want to see happen with that
> capability." Anyone singing the song of "Lets keep this from
> happening" is just laying more cement into the Maginot line. Its
> happened. Its over. There is a national ID system, there is a global
> ID system in fact, and using it, any two arbitrary databases anywhere
> in the world and do a merge to come up with a single match.
> What now?
While I'm by no means a fan of the "one big database", you raise an
interesting issue. One of the monster problems with databases of personal
information nowadays is the data quality issue: my name isn't *that* hard
to spell, but no-one seems to get it right, and that's just the beginning.
Another problem is visibility. I have *no* idea how many databases have
information about me, and how accurate any of it is, not to mention how to
correct it, view it, etc.
As you say, the reason now to oppose one big database is that the cost of
a merge of lots of tiny (and not so tiny) databases because the of the
lack of a good primary key is so high that we can let technology make
merges too costly. But if the cost of a good primary key drops to the
point where anyone who (say) commits a crime or gets a mortgage has to
provide the ID, where are we?
If we're *really* stuck with a unique "primary key", should we instead
push for one big database of personal information, with the
ability/requirement to federate data to it (medical data, tax data, credit
data, magazine subscription data)? If the law required both visibility of
both private and public data, and the use of the GUID, then perhaps we can
by policy and technology get better control over data.