Re: Operationalize orthogonality
Date: Mon, 5 Jun 2006 09:04:19 +0300
"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> x wrote:
> > mAsterdam wrote:
> >>Tony D wrote:
> >> > ... the relational model is orthogonal to type. That
> >> > means the relational model makes no demands and imposes no
> >> > restrictions on the types available (apart from the
> >> > obvious requirement for a boolean type).
> > I would say that there are some requirements on the types:
> > - equality is defined
> With a demarcated type base the equality need
> not only be defined, but also communicated/shared
> between the TB (type base) and (the rest of?) the DBMS.
> So it seems the DBMS and the TB at least need a common
> language for specifying and implementing operators.
The language of the interface (the "protocol") ?
You forgot this.
> >>What would the requirements for a dbms be to have
> >>this orthogonality implemented?
> >>ISTM the dbms should not have native types
> >>(except boolean and maybe type generators
> >>like relation() and attribute() ) but instead
> >>rely on a lower level, external to the dbms,
> >>type system.
> > What is "external" in software ? Crossing an interface ?
> A protocol.
> >>This poses the next question: what would
> >>be the requirements for this type system?
> > Whose requirements ?
> Good question :-)
> The end-users of course would be the same
> as the end-users of the applications and the database.
> The database (via a hypothetical dbms conforming to
> the protocol).
> The aplication (via a language/app framework conforming
> to the protocol).
> Both the application and the database would need some form
> of garantuee (thinking of 'leases' like in DHCP, but longer term)
> that a used type will remain valid.
How complicated! It would not be easyer to follow Mr. Codd advice ? Domains, not types. Received on Mon Jun 05 2006 - 08:04:19 CEST