Re: Dreaming About Redesigning SQL

Dawn M. Wolthuis wrote:

> 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.

Perhaps.

But before you go down that road, you have to answer the following
simple, yet possibly difficult-to-answer, question:
   What problem are you trying to solve?

"Data persistence" is far too vague a term to be meaningful in its own
right -- the term needs some context to have any real meaning here.

We store data for a reason.  Similarly, we retrieve it for a reason.
The data we're interested in looking for and the way we are interested
in looking for it will have a huge impact on any data retrieval solution
one could craft.

The relational model of data storage and retrieval is just a model,
highly suitable to some things and not suitable at all to others.  The
amount of development work that has gone into it and the amount of use
it has gotten shows that the relational model is actually reasonably
good at meeting many of the data storage and retrieval needs that people
have.  As with any method, it has tradeoffs and drawbacks,

There is no magic bullet and there never will be (or so experience
says).  I have no reason to believe that the problem of data persistence
and retrieval is any exception to that.

If you have a particular set of data retrieval problems in mind that you
wish to solve, by all means feel free to develop the mathematical
foundation to solve them.  Feel free to tell us that the relational
model is not suitable for that set of problems -- we might even agree
with you on that.

But don't make the claim that the relational model is lacking as a
result of not being a storage and retrieval method that is suitable to
all problems, and that there is a Better Way that will Solve Everything.
Many have made such claims about many different technologies.  They were
wrong, too.


I may be misreading you and responding to arguments you aren't making or
implying, but if so I doubt I'm alone, based on some of the other
responses I've seen here.


By the way, language is only a means of expression, and the only sort
of question (relevant to this discussion, anyway) that a language is the
answer to is "what's the best way for me to express X?".  It is neither
an answer to the question of how to retrieve data nor is it a solution to
the problem of storing data in a persistent manner.  The answer to the
question of how best to query data is certainly going to be a language,
but the specific language one comes up with in answer to the question
will depend on what the person asking wants.  "English" is likely to
be the best answer only under certain circumstances.  SQL is likely to
be the best answer (or, at least, a very good answer) only under other
circumstances.  It just depends.  But as with any solution to any problem,
there is no one-size-fits-all solution.  As a mathematician, you should
know this: the English language is horribly inadequate for expressing
mathematical concepts.  That's why mathematicians don't use it as their
primary language for doing math.  Why, then, should we expect English,
or Java, or any other language to be any better for performing certain
kinds of queries against data than some other, more directed language?
Say what you want about SQL, but at least it was designed with querying
table-based data in mind and is at least somewhat good at its job.


-- 
Kevin Brown                          kevin@sysexperts.com