Dinamyc Function

On Aug 20, 3:27 am, aCe <acerah...@.gmail.comwrote:

Quote:

Originally Posted by

>.
my purpose to create this, is i can reuse my function without creating
ambiguous function.

Quote:

Originally Posted by

>>

You are looking to employ modern concepts of programming in
in sql. It is like expecting to find a copy of the New York Times
among the dinosaurs in the Jurassic period. This is a totally
unrealistic expectation. 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. It is quite foolish
to request a dinasour when what you really want is a bird.
You will find an example of the type of function your looking
for within a database system here:

http://beyondsql.blogspot.com/2007/...r-function.html
Sql mavens can take heart that IT will treat then better than
history treated the dinosaur :)

www.beyondsql.blogspot.comsteve wrote:

Quote:

Originally Posted by

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.