Re: two nasty schemata, union types and surrogate keys

And here you make a hideously common mistake, one that seems to be more common to governments for some reason, but happens in the private sector too.

The contents of a database are assertions of fact made by the providers
of said information. If you are running (say) an order entry database, it's
reasonably safe to assume that the assertions in the database are true.
Even then, errors in data entry (for whatever reason) may lead to database assertions that don't match the "real world" (i.e. are false.)
If the data arrives via entities who either don't care or are actively hostile to your goal in collecting data, your database is liable to be full of assertions that don't match reality. That doesn't make it not-a-database, nor does it necessarily invalidate the notion of collecting the (untruthful) data. It DOES mean that you must treat the database as WHAT IT IS -- assertions of fact, NOT fact.

It is usually permissible to proceed under the assumption that the assertions in the database ought to be true. (Unless you know better given the data source.) It is impermissible to assume that they MUST be true.

I find that people who take your position tend to ignore the need for voids, database cleaning, errors, etc. Maybe you are the exception but I don't believe it for a moment. :-)

Karl Received on Thu Sep 24 2009 - 13:42:19 CDT