Calling SQL from within scripting language, we don't need SP,.. unless we need workaround, because of DBMS has missing basic "must be" features.
Consider example: lack of identity in oracle (auto-increment ID) required to write trigger and SP to emulate it. Another example: lack of timestamp data type required to write another trigger. (BTW, even with triggers, it's impossible to implement in oracle, but that's another story...) Third example: lack of *atomic* multi-table update may require transaction defence line and SP code around.
On the other hands, do we ever pay attention that all above is not required when we operate on regular filesystem with files and just rely on atomicy and consistency of well-defined filesystem's operations.
Same was nearly true until MySQL didn't forget about web-centric usage base where it was growing from. Then, instead focusing on benefits of copy-on-write snapshotting, LIMIT and caching improvements, they migrated to "market demands" with cursors, sub-selects, SP and other attributes of "respectable DBMS"-es.
As of my personal opinion, if someone *really* need stored procedures, person need to take a look onto 4GL, (for example) Progress DBMS, and realize there is no any reasons to return back to any SQL.
As long as SQL is claimed to be *non*-procedural language (at least by idea;), adding such workarounds as [stored] *procedures*, must be considered honestly, isn't it? If so, why create any standards for mis-conception at all? SQL-99, SQL-2003,...
Well, well,.. reason is always there: the market. People know SP-s, people use them, create more and more workarounds,.. and you have to deal with them sometimes.
Of course, create or not your own workarounds, -- always still been your personal choice.
Slashdot Mirror
Calling SQL from within scripting language,
we don't need SP,.. unless we need workaround,
because of DBMS has missing
basic "must be" features.
Consider example: lack of identity in oracle
(auto-increment ID) required to write trigger
and SP to emulate it.
Another example: lack of timestamp data type
required to write another trigger.
(BTW, even with triggers, it's impossible
to implement in oracle,
but that's another story...)
Third example: lack of *atomic* multi-table update
may require transaction defence line
and SP code around.
On the other hands, do we ever pay attention
that all above is not required when we
operate on regular filesystem with files and just
rely on atomicy and consistency of well-defined
filesystem's operations.
Same was nearly true until MySQL didn't forget
about web-centric usage base
where it was growing from.
Then, instead focusing on benefits of
copy-on-write snapshotting,
LIMIT and caching improvements,
they migrated to "market demands" with cursors,
sub-selects, SP and other attributes of
"respectable DBMS"-es.
As of my personal opinion,
if someone *really* need stored procedures,
person need to take a look onto 4GL,
(for example) Progress DBMS,
and realize there is no any reasons
to return back to any SQL.
As long as SQL is claimed to be
*non*-procedural language (at least by idea;),
adding such workarounds as [stored] *procedures*,
must be considered honestly, isn't it?
If so, why create any standards for
mis-conception at all? SQL-99, SQL-2003,...
Well, well,.. reason is always there: the market.
People know SP-s, people use them,
create more and more workarounds,..
and you have to deal with them sometimes.
Of course, create or not your own workarounds, --
always still been your personal choice.