Re: Domains as relations
Date: Tue, 08 Oct 2002 13:45:40 GMT
Message-ID: <8kBo9.173$0I3.13779_at_petpeeve.ziplink.net>
Paul,
I think you are really onto something.
> For example, the integers (in a certain range maybe) would be
What this suggests to me is the following: there are two ways to define a
relation: by list or by rule.
> represented by a table with just one column that includes every
> integer. This need not be stored phyically of course, it would just be
> a logical thing.
In the DB world, we tend to think of all relations as being defined by
list. Basically the state of any given
relation at a given point in time is determined by a list of tuples. The
The closest thing I've got, in practical terms to a rule based relation is a view. I can think of the view as representing a relation, subject to some restrictions on views, and the selection rule in the view definition as being the rule that defines this relation. The problem is, with existing RDBMS products, the views all finally devolve down into tables, one way or another. So in the final analysis, rule based relations incarnated as views, end up being list driven behind the scenes.
You could define views based on the primitive views, and/or key columns of tables, in combination with each other.
You could require that every column be based on a view, using that view as
its domain. In the case of foreign keys, that would resolve down to the
column where the key values are listed, something I still have the habit of
calling a "primary" key.
In the case of many columns, the "domain view" of that column would resolve
down to one of the primitive views of the system, together with constraints.
I don't know where this leads, but it could be interesting. Received on Tue Oct 08 2002 - 15:45:40 CEST