steve wrote:

> Sql is fine for plodding thru mountains
> of data, that is what it was designed for. It is not for things
> that require agility and specificity, in other words it is a
> poor language for application development.

Yes, but so what? SQL is the database layer. It is, as you say, good
at being a database layer. It is not so good at being an application
layer, which is why you generally use something else (Crystal, Access,
VB, or what have you) for the application layer instead (though certain
portions of the business logic may be pushed down into stored procedures
for efficiency; SQL is good enough that this is reasonable to do).

http://www.penny-arcade.com/comic/2006/09/05

And then your own product seems to be schizophrenic: do you intend it
to be a database layer, application layer, both? Many of your articles
pertain to abstract operations that are equally applicable to any table,
such as "dense rank when sorted by <column(s)>". Now if it were an
application-specific thing, such as "hook up <column(s)> to <field(s)>
in this front-end screen I've laid out", then that would make sense;
and in fact Crystal, Access, VB, etc. have long offered such features.

But you seem to be suggesting data-centric abstractions, the sort of
things that the next version of SQL Server is liable to offer in a
simple fashion. And I want it to offer them. I don't want common
data-centric abstractions reduced from 20 lines to 10 lines; I want
them reduced from 20 lines to 1 line. And, in fact, for the "dense
rank" example, SQL Server 2005 has DENSE_RANK() which does just that.

You also mention scaling, here and there, and generally seem to wave
it off with "we'll address that last". If you intend to hawk your
product as an improved database layer, that won't fly very well.