Re: Dreaming About Redesigning SQL

Thank you, Seun, for asking your question with a bit of logic and not
gut-reaction emotional baggage (and for also asking a question of me
off-list so I could ramble). I'll try to make this more suscinct.

First of all, I have read Codd's 1970 & 1974 ACM papers, as well as
his "The Relational Model for Database Management, Version 2" book. I
have also read several books by Chris Date and by Fabian Pascal. I
held a dialog (that reads more like a monologue) with Pascal and it is
reproduced in total if you scroll to the bottom of the
http://store.tincat-group.com page and click on the Dick Pick / Ted
Codd Blue Brothers parody picture. I had not been reading this news
group until lately, but it strikes me that this is a group that might
be very entertained by that dialog.

I have a master's degree in mathematics and my father is a linguist.
I find the language of mathematics and the mathematics of language
both fascinating. My experience, however, is that I have run IT
project teams working with a variety of databases (and languages) and
have never seen any environment that is as agile for develoeprs (both
productive from the start and easy to maintain) than the teams I have
led that worked with the UniData database. I have worked with SQL as
well as both older and newer database languages.

So, nope, I'm not trolling. I've been doing some research the past
couple of years and I'm convinced that it is time to do something new
(and yet old) with data persistence.

I favor using Java for a variety of reasons, but am comfortable with
other languages as well, and think that using Java both for the
software application and for the constraints on the data, rather than
encoding constraints in some other language within a database, makes
for both a more agile development approach AND, surprisingly enough,
tends to make for better data integrity, although a lousy software
developer can certainly mess up either environment. Separating the
DBA from the software developer has definitely had a negative affect
on the speed with which software is developed and maintained, but my
experience (and intuition -- I don't, yet, have scientific evidence)
tells me that the benefits purported by the approach of having a dba
work on some centralized constraints on the persisted data outside of
the context of the use of that data have not really come to fruition
and/or are not worth the costs of using this approach (more on that
some other time).

So, while some might classify me as an idiot (men can be so emotional
sometimes ;-), I have several graduate classes in logic to my credit
and believe that I am approaching this topic quite logically, even if
my summaries skip some of the logical steps in the process. I have
thought about how to prove my points and since my point is really
about agility and quality in application software development and
maintenance, a competition to see what tools and techniques and what
data persistence approaches win such a competition might be the best
proof. The current industry benchmarks for databases tend to be
SQL-based and highly political, so let's put different approaches to
the test.

Thanks for asking your question and not just assuming I'm a nut
because I disagree with the current state of the industry on this
topic. I'm sure there are gaps in my thinking and I know some of my
opinions are based on intuition that arises from my experience, but I
do hope to have more proof in the future. I am also very willing to
adjust my opinions with convincing arguments and evidence and trust
that there are some on this list who work similarly.
--dawn

seunosewa(at)inaira(dot)com (Seun Osewa) wrote in message news:<ba87a3cf(dot)0310092217(dot)72098544(at)posting(dot)google(dot)com>...
> dwolt(at)iserv(dot)net (Dawn M. Wolthuis) wrote in message news:<6db906b2(dot)0310091212(dot)4f967cf5(at)posting(dot)google(dot)com>...
> > I would suggest ditching the entire relational model (as both overly
> > simplistic in its theory and overly complex in its implementation) and
> > start with English (that is one of the other names for the GIRLS
> > language). Note that language is also the starting point for putting
> > data in XML documents, but it sure doesn't seem to be the starting
> > point for XQuery, eh?
> >
> > --dawn
> > Dawn M. Wolthuis
> > www.tincat-group.com
>
> Please explain further. What do you really mean? Its natural for
> everyone here to think every word in that post was a troll unless you
> explain your views more clearly. You could not have expressed a more
> unpopular/unsupportable combination of ideas! Exactly how would we go
> about using language as a query tool? Is this AI? What would the
> underlying model be knowing how redundant and imprecise language can
> be? Tell what we may have missed.
>
> Seun Osewa