Re: a union is always a join!

[...]

>3.
>Is there a database theory that can establish a good database design
>which will not allow screwing up of history but which uses others
>data entry operations?
>For example, in my db model (you can see it at www.dbdesign11.com), I
>am using in fact only one data entry operation. I am not using deletes
>and updates.

If I understand it correctly, you propose to annotate all facts (tuples) in the database with metadata about their insertion and retraction (when, by whom, possibly more). Every INSERT, UPDATE and DELETE becomes an INSERT. The database records not only the present state of affairs, but also all past states, and more (e.g. for every state change, who made it). Essentially you add version control to the database. System exist that do this.

Why do you describe this as a new data model? It seems more palatable and more useful to describe it as a particular way of using relational databases. You might add descriptions of transformations of database schemas, instances and queries that convert an arbitrary relational database into this form, and of the reverse transformations that, given a database in this form, convert it to one that only ever holds the current state of affairs (or transformations that take a read-only snapshot of any particular state, like in version control systems). Such transformations can help demonstrate that your database operates as designed.

(I also notice that all of your tuples have an object id, but that topic has been trampled to death in this group.)

>Vladimir Odrljin

-- 
Reinier