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: [EMAIL PROTECTED] phone: +64-9-9184573 cell: +64-21-467747 other: MSN [EMAIL PROTECTED], skype: rvowles blog: http://www.usergroup.org.nz/blogs/selectBlog.html?id=39769 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
