[DUG] Why InterBase

[Richard Vowles]

I'll answer the second part first and  the first part second.

Application server layers are scalable, you can just add more of them.
There are more and more people who wish to scale adding distributed
caches as well (open source ones), where the entire database is sucked
into memory and the distributed cache deals with everything, making it
ever so much more scalable. They work, they are in operation, you just
have to have a bit more money for machines that can have lots of memory.


Databases are by definition a single source - you can get replication
but that turns messy really, really quickly. Going for more than two
sources causes grief beyond measure, and there is a lot of code behind
those who do have to implement these models successfully.  Most big
organisations in New Zealand have two (one in Auckland, one in
Wellington, sometimes North/South Island).

Your first point about me missing the Accredo meeting - well two points
about that. First you know I was in Wellington and that I was annoyed I
missed it :-( Secondly, you keep all this cool technology to yourself
anyway, so it is like leading a starving man to a banquet and showing it
to him and not letting him take part :-) I understand the reasons (time,
focus, competitive advantage) but sometimes you can be just too mean :-)

Richard

---
Richard Vowles, Solutions Architect, Borland New Zealand
email: richard.vowles at borland.com
phone: +64-9-9184573
cell: +64-21-467747
other: MSN richard.vowles at borland.com, skype: rvowles
blog: http://www.usergroup.org.nz/blogs/selectBlog.html?id=39769

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz]
On Behalf Of Paul Heinz
Sent: Thursday, 1 June 2006 4:15 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Why InterBase

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.





_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi