Re: 3vl 2vl and NULL

From: dawn <>
Date: 7 Dec 2005 04:16:22 -0800
Message-ID: <>

Frank Hamersley wrote:
> dawn wrote:
> > Frank Hamersley wrote:
> >
> >>dawn wrote:
> >>
> >>>David Cressey wrote:
> >>>
> [..]
> >>>
> >>>Every language has pros & cons. SQL's big pro is its wide use,
> >>>adoption in client-server approaches such as odbc & jdbc, and by most
> >>>database vendors. Maybe once those who have only worked with SQL start
> >>>working with other tools (perhaps related to data in XML documents),
> >>>there will be a move toward 2VLs end-to-end in software development.
> >>>Then Mike can be in the mainstream and we won't need to change HIS
> >>>mind. cheers! --dawn
> >>
> >>I for one am not holding my breath on this one!
> >>
> >>The 2VL offerings have had plenty of time for market forces to make a
> >>reliable judgement (viz Darwins Theory of Natural Selection). They are
> >>certainly not dodo's but they are definitely not a top order success story.
> >
> > What do you use with XML structured data? A 2 or a 3VL? Answer: 2VL,
> > right?
> Nope - but a poor question anyway - to my way of thinking XML is not
> "structured data" - period.

I should have written it as "XML-structured data." You might not like the structure, but surely XML does provide a structure.

> That said it seems to present no problems
> to the SQL vendors AFAICT.

I have not seen the ability to point SQL at a set of XML documents, but I would really like to see that. Do you have a url?

> It is a handy way of transferring information between disparate systems,
> but just because it carries its schema embedded in the data stream, does
> not make it "structured".

I can model data and implement it according to the structure indicated by the XML specification. Do you have a definition for the way you are using the term "structure"?

> In fact XML has to be 2VL, not because 2VL is
> desirable, but because it has no capacity to record "special" values.

I'm not an XML expert, but I'm pretty usre you can pass any unicode characters. It would be languages that worked with XML that might or might not have special reserved word names for one or more characters (or groupings of characters).

> > List all languages that employ a 3VL that are in common use today.
> > 1. SQL
> > 2. ?
> >
> > What am I missing? --dawn
> I'd hazard the "Market Share" component?

I suspect that the pie you are working with is something smaller than mine. I'm interested in the area of software development rather than some narrower pie such as SQL-DBMS products. It appears to me that products that use a 2VL are on the rise. Software developers are more likely to employ a 2VL end-to-end in development today than yesterday and even more likely tomorrow, I suspect.

> You could also count the
> number of distinct DBMS vendors offering 3VL product - even so 2VL loses.

You are likely right that a 3VL is employed by the bulk of the current DBMS vendos, given that for the past couple of decades SQL has been top dog, but I'd be interested in seeing that pie today and in five years. Tools might still all implement SQL, but they don't have to have their primary or native tongue be a 3VL.

> BTW - I did giggle at the use of the generic term "languages" to expand
> the domain in your favour by letting the "database" aspect of DC's post
> fade.

I wasn't intending to expand the domain. My interest in database theory and data modeling is related to the area of software development. You might carve out another domain related to your own purposes for chatting about database theory. In response to your statement that 2VLs were not a "success story" (that I don't see or inadvertantly snipped in this posting) I would certainly disagree. Developers often write software that uses very current technology on the front-end (e.g. AJAX) by using exclusively two-valued logic, often then working with SQL on the back-end. I prefer to employ a 2VL (along with non-1NF) end-to-end and I suspect that approach is on the rise.

> Cheers, Frank.

And cheers to you too. --dawn Received on Wed Dec 07 2005 - 13:16:22 CET

Original text of this message