Re: Domains as relations

"David Cressey" <david_at_dcressey.com> wrote in message news:<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
> > 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.
>
> What this suggests to me is the following: there are two ways to define a
> relation: by list or by rule.
> 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
> list of tuples is stored in a table, one tuple to a row.

> Those of us who work with DBs tend to think this way so much that we don't
> think of rule based relations. Please correct me, someone, if there is an
> accepted mathematical term for what I'm calling "rule based relations".

Aren't Constraint Databases the field you are looking into?  

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

Not true today. You can program a "table function" -- a procedural code which output is a view. http://www.dbazine.com/tropashko2.html says more about it. Received on Tue Oct 08 2002 - 20:20:45 CEST