Re: arrrgh Why Java over PL/SQL

You are very right; there is no panacea however, many people shoot themselves in the foot by underutilizing the capabilities of their RDBMS. Here is an excerpt of what Tom Kyte wrote in this repect, in his foreword of my book:

... I have found that too many people approach the database as if it were a black box-something that they don't need to know about. Maybe they have a SQL generator that they figure will save them from the hardship of having to learn the SQL language. Maybe they figure they will just use the database like a flat file and do keyed reads. Whatever they figure, I can tell you that thinking along these lines is most certainly misguided: you simply cannot get away with not understanding the database and how best to work with it.

That is where this book comes in - it provides a balanced view of how a Java programmer can approach the Oracle database and use it successfully. Where and when database features such as stored procedures make sense - and how they fit in....

Kuassi

Vladimir M. Zakharychev wrote:
> klabu wrote:
> > arrrgh !
> >
> > Our backend enviornment:
> > 10gR2 <---> TIBCO <---> Java
> >
> > <rant>
> > can someone please explain to me why is the damn bloody Java layer necessary
> > ?????
> > Am I daft to say PL/SQL can very well handle it ?
> >
> > and that AQ can replace TIBCO ?
> > <rant/>
> >
> >
> > comments please
> > --
> > 10gR2
>
> Most probably because people with insufficient knowledge of Oracle
> out-of-the-box functionality tend to make things more complex than they
> could/should be and reinvent their wheels... Some are afraid of "vendor
> lock-in" and significant costs associated with migration to a different
> platform if at some point the current platform is abandoned for any
> reason. They want to be "platform-independent", which Java seemingly
> grants them, and they tend to consider the database (any database) just
> a mere dumpster they throw their data in, sometimes retrieve, process
> and throw back in using minimum subset of SQL common to all RDBMSes and
> completely ignoring what else their particular DBMS is capable of, even
> though good money were paid for it and by not using its capabilities
> they are throwing away that money. There are surely other reasons as
> well.
>
> However, not knowing exact requirements of the task at hand it's
> impossible to say if your current architecture can be
> replaced/reimplemented with PL/SQL and AQ, maybe with a bit of
> server-side Java. Actually, if it currently works, and works
> sufficiently well, I wouldn't strive to replace it with a solution that
> might be better, but might as well be worse...
>
> Regards,
> Vladimir M. Zakharychev
> N-Networks, makers of Dynamic PSP(tm)
> http://www.dynamicpsp.com
Received on Sun Dec 17 2006 - 15:16:25 CST