Path: news.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!news.he.net!cyclone-sf.pbi.net!64.42.15.2!HSNX.atgi.net!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail From: pbrazier@cosmos-uk.co.uk (Paul) Newsgroups: comp.databases.theory Subject: Re: Domains as relations Date: 10 Oct 2002 08:52:29 -0700 Organization: http://groups.google.com/ Lines: 65 Message-ID: <51d64140.0210100752.7c354984@posting.google.com> References: <51d64140.0210080104.f79cbee@posting.google.com> <8kBo9.173$0I3.13779@petpeeve.ziplink.net> NNTP-Posting-Host: 195.92.141.89 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1034265150 30661 127.0.0.1 (10 Oct 2002 15:52:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 10 Oct 2002 15:52:30 GMT Xref: newsfeed1.easynews.com comp.databases.theory:22916 X-Received-Date: Thu, 10 Oct 2002 08:52:26 MST (news.easynews.com) "David Cressey" wrote in message news:<8kBo9.173$0I3.13779@petpeeve.ziplink.net>... > I think you are really onto something. onto something or on something? :) > 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. Well you could think of relations defined at two different levels: one in the usual way at the logical level which would be ultimately list-driven. The other at a lower physical level which internally would be rule-driven, but which would manifest itself as list-driven at the logical level. So if your DBMS had a table for integers (or a subset) it wouldn't actually store them all but create the relation/view on the fly whenever you did "SELECT * FROM integers" or whatever. Actually just thought maybe if you had a table with just 0 and 1 in it in the same column then cross join it with itself enough times you'd get a view that could be interpreted as a subset of the integers in binary form. (if you concatenate the digits together). So perhaps your only "built-ins" would be 0 and 1? But then it would be like implementing a model of a computer in your DBMS so kind of chasing your own tail. > What if the rule on views were relaxed at little. What if the system > contained a few "primitive views" that defined such relations as "the set > of all integers that will fit in a given word size". That's finite, but > you really don't want to make a list of them. Or a primitive view "the set > of a character strings of length 5". What now? I'm going to look into constraint databases a bit more as mentioned elsewhere in this thread - maybe they provide a way that you wouldn't even need these "primitive" or "physically defined" views? I get the impression from a brief look that they are basically there to provide a way to extend relational theory from finite to infinite sets. Separate from the issue of infinite sets though, it would be nice to have everything in a DBMS stored in relations - domains, DML, DDL, DCL, constraints, etc. So it becomes completely a closed (self-referential) system instead of having a query language as a distinct thing perched on top of the relational database, and domain systems slotted in underneath it somehow as well. Is this just a theoretical niceness though? I noticed an article along similar lines on the www.dbdebunk.com website (On variables and values) coincidentally just after posting here. The point was that it might actually be a good thing to separate things out and group together things like queries & domains as distinct from plain "data" relations. Kind of like how we don't program in machine code, or like set theory defining numbers in terms of the empty set e.g 0={}, 1={{}}, 2={{},{{}}}, ... n=union(0,1,...,n-1) but it being more useful to *not* think of numbers as sets. Maybe Codd was wrong when he stipulated that everything in a DBMS should be accessed via relations. Or maybe there is a distinction made between data and programs - is this a valid or useful distinction though? I get the feeling that I'm thinking in circles. Paul.