Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Implementation of boolean types.

Re: Implementation of boolean types.

From: dawn <>
Date: 19 Jul 2005 21:22:48 -0700
Message-ID: <>

Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:
> >
> > Yup! I've worked with tools that have a null value (yes "value") that
> > models the null set and I've worked with SQL and it is so much easier
> > and more intuitive to work with a 2VL and null value = empty set model.
> > Design, development, trouble-shooting, and maintenance are all
> > significantly easier with this model.
> >
> > This is one of several features where those attempting to implement
> > relational theory took what was working in databases in the 70's (such
> > as 2VL) and mucked it up, contributing to greater cost of ownership for
> > data-centric applications.
> Hmmm. I detect that perhaps you are trying to identify this issue
> as being somehow a consequence of RM? If so I would not agree;
> the issues are independent.

Even if current RM theory accomodates 2VL, is it historically inaccurate for me to suggest that before Oracle and other SQL-DBMS products became popular most developers working with stored data were using 2VL, putting ^000 or low-values or some such in "empty" fields? I admit that I did not research it, I just lived it and certainly not all of it. I think of SQL as bringing the 3VL into popularity, but I could be wrong. Attempts to implement the RM have been almost exclusively with SQL-DBMS's, so practically speaking it is the products that stem from the RM that have brought this on, whether they needed to (and we know they didn't) or not.

> > Taking just this one issue, I suspect the
> > path to getting the industry from here to there is via XML/XQuery,
> > perhaps? However, I did read that SQLServer has an option of switching
> > from 3VL to 2VL.
> I don't think I'd agree with this either. SQL needs to be replaced,
> not fixed,

Complete agreement on that point.

> and the XML-family of technologies are fundamentally
> flawed.

I agree with that too. In fact, all models and all products are flawed, but some are more useful than others, right?

> I don't think any "data management" system that doesn't
> have a type system or a schema in version one is going to go anywhere.

I think you might have to eat those words, but we shall see.

> You can't retrofit these things; they have to be designed in from
> the start.

Certainly preferred and there will definitely always be flaws, but I don't think we are too far off from significant changes in the database world and XML will surely play I roll.

> (Yes, I know XML now has various ways to specify schema,
> with at least DTD and XMLSchema. [Does anyone anywhere think they
> are good?]

Not I, brother.

> Reminds me of the old saw about a man with two watches.)

I must be too young to know that one, so feel free to fill it in

> Anyway, XML doesn't address data management; it's a document
> management system.

Sure XML is just a format. But is a format that doesn't play nice with SQL-DBMS's (and, yes, I know of everybody and his brothers adapters with one end connected to the SQL-DBMS and the other to XML, but some folks like me will want that unnecessary component out of there).

Somewhere between the SQL-RDBMS and the Semantic Web, exclusive, lies a model and implementations thereof that will do a big-bang-for-the-buck job and developers will flock to it -- perhaps a hosted database with an intuitive interface and constraint-handling that permits end-users to add their own new attributes (having just read the other thread on that).
Cheers! --dawn

> Marshall
Received on Tue Jul 19 2005 - 23:22:48 CDT

Original text of this message