Re: a union is always a join!

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sat, 28 Mar 2009 09:51:11 -0400
Message-ID: <jXpzl.10900$%54.1374_at_nlpi070.nbdc.sbc.com>


"Walter Mitty" <wamitty_at_verizon.net> wrote in message news:nr3zl.249$zg5.217_at_nwrddc02.gnilink.net...
>
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:TJ%yl.24805$yr3.3171_at_nlpi068.nbdc.sbc.com...
>>
>> "Walter Mitty" <wamitty_at_verizon.net> wrote in message
>> news:HrHxl.1597$6%.913_at_nwrddc01.gnilink.net...
>>
>> <snip>
>>
>>> Tegiri opined as to how an update is essentially the same thing as a
>>> delete
>>> followed by an insert. An eminently reasonable proposition,
>>> given that any delta in a database that can be caused by an update can
>>> also
>>> be caused by a suitable delete followed by a suitable insert.
>>
>> If a user issues an insert, isn't it reasonable to assume that it
>> concerns something that isn't already represented in the database? If a
>> user issues a delete, isn't it reasonable to assume that it concerns
>> something that shouldn't still be represented in the database? If a user
>> issues an update, isn't it reasonable to assume that it concerns
>> something that should still be represented in the database? If those
>> assumptions are reasonable, then the assumption that an update is
>> essentially the same thing as a delete followed by an insert isn't.
>>
>> The assumption that an update is essentially the same thing as a delete
>> followed by an insert effectively denies that there is a connection
>> between a database and the universe of discourse. And that is just
>> absurd.
>>
>> <snip>
>>
>
> It's exactly the opposite, Brian. The assertion that a given state of the
> database makes different assertions about the UofD depending on how the
> database got to that state is what breaks the connection between the
> database and the UofD. It's the current state of the database, and not
> the history of the database, that makes assertions about the UofD.
>

You're being short-sighted. A relational database that states not just what has been the case since the last update, but what has ever been the case is called a historical database. It is a simple matter to define a set of views on the historical database that represents just what has been the case since the last update: restrict each relation to just those tuples that have indefinite intervals, and then project away the interval attributes. Moreover, every delete, insert or update that target those views maps to an update, an update and an insert, or an insert against the historical base relations, given the point in time that the delete, insert or update occurs. So in effect, it can easily be argued that a database that is not historical is essentially just a view on one that is.

> This is the nub of the debate between you and me. Let's let it rest here.
> I'm not going to change your mind. And you're not going to change my
> mind, or the minds of most of the participants.
>
Received on Sat Mar 28 2009 - 14:51:11 CET

Original text of this message