Re: Why are data types size limited?

From: Carl Rosenberger <cr_at_c-ros.de>
Date: 2000/04/12
Message-ID: <8d2ie7$7r3$1_at_news02.btx.dtag.de>#1/1


Does anybody have an educated guess on the future lifespan of SQL as a standard for database applications?

In my opinion OODBMS are a better representation of reality.

Carl

William Boyle <woboyle_at_ieee.org> schrieb in im Newsbeitrag: 38F4C6AF.CE1C818B_at_ieee.org...
> joe_celko_at_my-deja.com wrote:
> >
> > >> From an ignorant-user standpoint, they {SQL databases} are great
> > except for field size limitations ... Why is this? Why can't databases
> > be written to handle arbitrarily long strings, and grow or shrink all
> > input fields as needed? <<
> >
> > That is actually a good question. When we were doing the SQL-86 and
> > SQL-89 standards, we knew that SQL really stands for "Scarely Qualifies
> > as a Language" -- a little ANSI humor.
> >
> > The specs do not talk about internal representation of data types in
> > the SQL database, only scale and precision, character sets, and other
> > abstract things. The reason is that you never directly see SQL data!!
> > The database exists in one place, the host program exists in another
> > place and the SQL engine passes data back and forth between them,
> > converting datatypes on the fly. This is why 'C' and Cobol can use the
> > same database.
> >
> > The datatypes we picked were the most universal, easiest to map to host
> > programming languages we could imagine.
> >
> > --CELKO--
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> That reminds me that the original definition of SQL, back in the lab at
> Sta.Teresa (IBM) was Simplified (or Simple-minded ;-) Query Language. It
> was intended for management types who couldn't think logically to save
> their souls (if they have one). Of course, it quickly became so obtuse
> that no reasonable person can express any reasonably complex
> relationship with it. I often bemoan the fact that QUEL wasn't more
> widely adopted. It may not have been particularly great, but it was much
> better than SQL. However, the one query language which I really liked
> was ZIM, which supports full ER models. Really powerful set processing,
> and implied join (including recursive and self join) semantics via the
> use of defined relationships.
>
> Bill Boyle
> woboyle_at_ieee.org
Received on Wed Apr 12 2000 - 00:00:00 CEST

Original text of this message