Re: two nasty schemata, union types and surrogate keys

"Roy Hann" <specially_at_processed.almost.meat> wrote in message news:E9WdndR88KjfsyrXnZ2dnUVZ8v2dnZ2d_at_pipex.net...
> Brian wrote:
>
>> Databases don't record objects: they record facts [...].
>
> Admirably close, but not quite cigar-worthy. Databases record
> *assertions* of fact. The assertsions may be sincere and truthful, or
> sincere but false, or deceitful and false. As I have said before, it
> is useful to think of the content of a database as being like the
> testimony in a court case.
>
> My point being: you don't care, and we don't have to care (for the
> purpose of designing the database or the software that operates on it),
> about facts. All that matters is that we can make the inferences that
> we should be entitled to make from the assertions. Whether the
> inferences turn out to be factual or not is just not our business.
>
> I can't bring myself to discuss the indentity issue. I am hopelessly
> bored with the idea that every particle and every concept has a
> barcode buried in it somewhere if we look hard enough. The problem of
> identity is always solved by the business process, and if it isn't,
> that's life's way of saying it doesn't need solving.
>

Excellent response!

My own point of view is slightly different from your last sentence.

I was around computers at a time when a lot of purely manual business processes were computerized for the very first time. (I had originally written "automated", but I deliberately changed the wording to "computerized".) When you analyzed the processes in place, you found innumerable references to the fact that human beings make decisions on the basis of inadequate and contradictory information, and do so pretty successfully.

So, if you asked a registrar "what do you do if there is more than one student named 'Paul Smith'" the answer would generally be "you just have to use your common sense." The construction of reliable systems at that time involved repeated cases of substituting some formal mechanism for "common sense". This includes, but is not limited to, formal mechanisms for identity.

Nowadays, almost all systems that are to be programmed inherit a legacy system that is already computerized. Hence, the dependency on "common sense", if any, is not as evident as it was some thirty or forty years ago. A lot of people who decide to start from scratch, and not to inherent the conceptual flaws of the legacy system, discover that the legacy system has been making irrational and unfortunate decisions for lo these many years, and people have been living with it for a variety of reasons. A lot of other builders never quite go be to starting over, even when they do a complete code rewrite. They inherit the conceptual flaws of the legacy system, and go from there. After all, the ultimate acceptance test is likely to be running the new system and the legacy system side by side for a few months to see if the new system is "good enough".

This doesn't deal with the issue that you are hopelessly bored with. But I hope it sheds some light anyway. Received on Mon Sep 21 2009 - 14:05:24 CEST