Re: Domain Definition

"D Guntermann" <guntermann_at_hotmail.com> wrote in message news:<H8Ir38.Dxr_at_news.boeing.com>...
> You mean vendors are getting away from the notion of type=table??? If not,
> then I would have to disagree with your assertion that today's products are
> perfectly capable of supporting domains.

   To my knowledge (and I wrote a book about this) no one in the DBMS research   or product community *ever* equated domain/class/type with table to the   neglect of other ideas. The Object Database community regularly brought up   class-as-table as a straw-person system model that they could then dismember   (quite reasonably) but object class-as-table was never the model followed by   real [O]RDBMSs.

   Postgres tried out table-as-type and was widely copied, but that was an   experimental system that also supported two other user-defined domain/type   mechanisms. For this discussion the most important of the alternative   ideas was a 'C' struct as physical representation and 'C' functions for   new domain operators. Postgres used the word 'TYPE' for both the table row   structures *and* the new 'domains', which was a marketing mistake.

   The current crop of commercial and open source [O]RDBMS products also   support this 'dual' mode (though your mileage will absolutely vary wrt.   the quality of the underlying implementations).

   Sadly, some commentators were very eager to point to the features they most   disliked and overlooking some stuff that did (more or less) exactly what they   were asking for. Should Date & Pascal's TRDBMS engine be built, its going to   re-use a lot of Postgres engineering (different parser, but that's about all).   Types to define tables was a half-baked idea that was useful for table   inheritance (also a half-baked idea). But have a look at the PostgreSQL web   site and the way it supports 'OPAQUE' types (and has since 1989).

> If so, then do does this domain support include distributed DBMS
> interaction?

    Yes and no.

    i. The truly hard problems have to do with the fact that a distributed DBMS

       supporting extensible domains must provide some means of *logic* as 
       well as data location transparency.

   ii. The data part is actually pretty easy. When you implement a new domain/
       type you need to implement a pair of functions to convert the physical 
       format into a platform neutral one and back from the neutral format to 
       the local format. This ends up being ASCII, but it works. 

  iii. Moving logic is ***really*** hard. The general strategy is to avoid 
       doing so: the space of possible query plans is constrained based on 
       what logic (domain operators) is bound to what physical machines.

   iv. There is an unreleased version of one commercial system that does 
       support distributed data management over user-defined types/domains 
       although it does so with a raft of caveats. For a number of reasons 
       this will probably never see the light of day. 

  I would encourage everyone to look at what Postgres does. It's one slick   system.

   KR

          Pb Received on Sat Jan 11 2003 - 05:21:54 CET