Re: two nasty schemata, union types and surrogate keys

From: Brian <brian_at_selzer-software.com>
Date: Fri, 25 Sep 2009 04:19:56 -0700 (PDT)
Message-ID: <1091dc4c-c1fd-4174-b949-9212a314698e_at_y20g2000vbk.googlegroups.com>


On Sep 24, 2:42 pm, kschendel <schen..._at_kbcomputer.com> wrote:
> On Sep 22, 10:13 am, Brian <br..._at_selzer-software.com> wrote:
>
> > ...  But if I don't suppose that what is in the database is
> > true, then there's no point in even having a database. ...
>
> 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.

An assertion of fact IS a fact. Appealing again to Webster, a fact is 'a piece of information presented as having objective reality.' Isn't assertion a kind of presentation?

If the sources of information may be suspect, then the source should be recorded along with the information so that it can be taken into account in queries. When the source is part of the record, then what is in the database is an assertion of the form, 'so-and-so said such- -such,' which may safely be treated as being true even if such-and- such isn't!

>
> 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.

Why do you insist on introducing the modalities ought and must? Keep it simple stupid!

> 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.  :-)

What position is that? The position that what is given is supposed to be true? I really can't believe I need to defend what is obvious to anyone with even a rudimentary grasp of logic. Nothing I have written here argues against validation or constraints or any other available mechanism for keeping garbage out of the database or for removing garbage from the database.

>
> Karl
Received on Fri Sep 25 2009 - 13:19:56 CEST

Original text of this message