[DUG] Why InterBase

[Paul Heinz]

Richard wrote:
> Its funny isn't it that architecturally all evidence says "don't put
> your stuff in stored procedures" - it is hard to port and impossible to
> scale. On the other hand, every vendor wants you to do it because it
> ties you to them :-)

Well, there is a <gasp> standard for SQL stored procedures called SQL-PSM
(persistent stored modules). However, as you point out, almost no engine
vendor implements it but rather their own incarnation. Actually, to be
precise MySQL and DB2 do implement PSM as part of their SQL:2003 support
because they added stored procs very late in the piece.

And you missed our Accredo DUG session where we showed our SQL stored proc
babelfish translating from PSM into MSSQL, FB/IB and Oracle :-)

So, portablity is solveable. :-)

And I'm not sure quite what your metric is for scaleable.

If you mean that the stored proc languages in most engines aren't as well
tuned as a server java VM, you've potentially got a point, but you're still
be wearing either cross-process or even cross-machine round-trip losses so
I'd imagine a stored proc would beat an application server in a lot of
cases.

Even if you throw more CPU at the application server, it's still going to be
rate limited by how much data the database engine can pump so you should
ramp the specs on the database server too.

All hand-waving and IMHO, of course :-)

TTFN,
  Paul.