On Oct 19, 7:24*pm, Serge Rielau <srie...@ca.ibm.comwrote:
>Faszinating thread.
I should think we could use many more :)
>Disclaimer: The following has nothing to do with the OP's real world
issue that he has no control over, but is meant to steer against the
polarized views been flushed up here....
I hope your not using 'polarizing' pejoratively. Lets eliminate as
much doubt as we can in the readers mind as to what we mean. Polarized
views should be healthy. We built a judicial system upon it. And after
all I'm sure we both agree we wouldn't kill each other:)
>The S in SQL stands for structure.
To many the 'S(tructure)' is the declarative nature of the language.
And given the keywords of the language used declaratively this equates
to relational. It does not.
>Making just about everything in a query a variable is not structure.
Another polarizing view:) A rose is a rose is a rose. A variable is a
variable is a variable. You seem to feel that something is lost when
you introduce the idea of a table as a variable and a query itself as
a variable. What is lost? It's more a question of what is gained.
Would a user think twice about an integer expression with variables?
The question of 'losing' something with integer variables in an
expression (as opposed to constants) would never occur to someone (I
hope). The relational idea is simply to transition users with the same
mindset using integers and strings to expressions using tables. Put
even more simply it is to introduce assignment with tables and you
can't talk about assignment without variables. Sql has managed to
define itself independent of a computer science known to developers. A
relational db is putting basic computer science back in the database:)
>It is the ultimate of freedom (and risk).
What is the nature of the 'risk' you see? Besides, given the level of
abuse of sql in IT today could the introduction of new ideas possibly
raise it significantly? When it comes to risk we have nowhere to go
but down:)
>A DBMS is meant to be finely tuned to the application and that implies
that the interactions are largely well known. That way indexes can be
created, table designs chosen, etc.
How relational ideas would somehow undermine things in beyond me.
Today we have dbs that can do everything with an index and virtually
nothing with a key. Does
a SELECT statement have anything to do with the concept of a key? Do
we want
b-tree experts or application developers? Today there are only
performance hints. Do
you think users will object to 'logical' hints?
>Dynamically composed SQL (and let's not kid ourselves: table variables
are nothing other than dynamic SQL in a different skin) allow for a lot
of curve balls to be thrown at the system resulting in quite
unpredictable outcomes w.r.t. service level agreements.
E.g. statement caching becomes a real challenge and so does problem
determination.
Do you see something 'dynamic' as a consequence of implementing a
relational (as I'm advocating it) db? I don't really know where you're
coming from here:(:) I do know that from the relational viewpoint
dynamic sql is the sql attempt to work with a table as if were
relationally realized. It's the sql workaround to simulate a variable
from a static structure. Just like relational division (the ability to
'directly' compare tables) is simulated in sql with aggregate
functions.
>In other words SQL is what it is because the experts in relational DBMS
figured that is the proper and performant way to do it.
Anyone who wants something different is free to do it their way (XQuery
anyone? Map Reduce? Streaming?)
Well Alan Greenspan convinced everyone derivatives and non-regulation
were good for the economy:(:) I'm actually less interested in tearing
down sql than creating room for something else for application
development. But sql holds such a monopoly in IT that it's hard to
create an opening for something that looks similar but is very
different. Sql has co-opted the broad ideas of a relation database
making it appear to most users as if they are one and the same. The
great deception of "relational-like". So separating the two remains a
moving target:)
>Instead of pointing to MS SQL Server Blog articles I'd point to academic
papers if I wanted to make a scientific point btw.... (I certainly
wouldn't point to any of my DB2 articles to argue language theory...).
And just because something is possible (tables as parameters,
associative arrays, ...) doesn't mean it's the best tool.
Criticizing is easy, being a critic is difficult. Most users have
deprecated scholarship much like a db deprecates certain features. The
industry has historically succeeded in marginalizing sql critics, even
the truly scholarly ones. Such inconsequential criticism comes from
relational purists, theorists and academics divorced from the 'real'
world of IT. Most evangalists from vendors, with vested interests and
turf at stake, trivialize criticism regardless of the shamefulness of
some their arguments (or excuses). On the other hand many critics of
sql do not fall short of foolishness.
The ad hominem attackers and the 'throw it all out' crowd. The idea
that the enormous amount of scholarship contributed by so many in the
development of sql dbs should somehow be dismissed is stupid and
absurd. In view of such a polarized environment and given the track
record of the various sides why not point to my own articles as a
point of reference:) Given it's still very much a QBE world why not
toot my own horn:) I'm arguing less theory than illustrating
practicality. Perhaps it takes something more (or less) than
'scholarship' to open the door and interest users to
something other than sql as the foundation for application
development.
best,
steve
www.beyondsql.blogspot.com