XPost: comp.lang.java.programmer   
   From: e@t.me   
      
   "Mark C. Stock"  wrote in message   
   news:_4GdnUcnXPoxFYXfRVn-iQ@comcast.com...   
   >   
   > "Haximus"  wrote in message news:KEVRd.13245$NN.11844@edtnps89...   
   >>   
   >> "DA Morgan"  wrote in message   
   >> news:41d8219f$1_1@127.0.0.1...   
   >>> fishfry wrote:   
   >>>> In article ,   
   >>>>  "Tom Dyess"  wrote:   
   >>>>   
   >>>>   
   >>>>>Yes, I would agree with the relational database. ORDB are mainly hype   
   >>>>>and usually promoted by coders that have never had to write a report or   
   >>>>>mine data effectively.   
   >>>>>   
   >>>>   
   >>>>   
   >>>> Is this really true? I'm an experienced database programmer learning   
   >>>> the Java/OO way of doing things and I'm puzzled that people use   
   >>>> Hibernate and similar tools to define objects, with the database   
   >>>> serving as just a passive serialization mechanism with no thought to   
   >>>> database theory. How can this possibly work in real life? Also I've   
   >>>> been told that stored procedures are not supported by Hibernate, is   
   >>>> that true? How can it be that 20 years of relational theory seems to be   
   >>>> getting thrown out overnight? Or am I just misinformed?   
   >>>   
   >>> It is true. Most of the Java being written against relational databases   
   >>> doesn't perform and doesn't scale well. The saving grace for all of   
   >>> those Java geniuses is that they can blame it on the web and 99% of IT   
   >>> management is too clueless to know better.   
   >>   
   >> That is pure opinion but you're welcome to it.  I'm not sure why   
   >> relational purists are so biased against Java, but I can't think of a   
   >> single programming language that has increased the productivity of   
   >> programmers more than Java.  Personally I prefer Java Stored Procedures   
   >> to PL/SQL because they are far quicker to develop and easier to debug,   
   >> not too mention the performance is comparable and sometimes superior when   
   >> using the native libraries.  I can't understand why someone would choose   
   >> clunky old PL/SQL unless they are stuck in "the old days."   
   >>   
   >   
   > i've not programmed much in Java and OO (yet), but i'm well-qualified as a   
   > PL/SQL dinosaur.   
   >   
   > however, i'm also well-qualified to have observed a tremendous decrease in   
   > productivity and an increase in complexity concurrent with the rise in   
   > popularity of Java and OO.   
   >   
   > i believe the current state of disorganization in oracle database and app   
   > server installation, configuration, and documentation is a symptom of the   
   > mentality that has accompanied the rise of Java, OO, and web technologies,   
   > of course complicated by oracle's traditional way of doing business.   
   >   
   > i don't dismiss Java and OO, i acknowledge their likely superiority for   
   > certain scenarios. but, like daniel, i have seen a good amount of myopic   
   > usage of the technology. my general experience in the field is to see it   
   > viewed as a magic potion that can solve any problem better than anything   
   > else, but often (yet not always) end up gumming things up by those who   
   > don't acknowledge the need to understand and use relational technology   
   > correctly.   
      
   There's no doubt trying to wrap OO around a relational database is going to   
   have "issues,"  but there's just no getting around the fact that you can't   
   build truly sophisticated client front-ends with PL/SQL.  My first Oracle   
   experience was with Forms 9i, and from the literature and my research it was   
   touted as the "RAD" tool to use.  I soon discovered that I did not like   
   PL/SQL very much and development was not at all rapid for my purposes, in   
   fact many of the language features available on the server-side were not   
   compatible with the client-side (for example associative arrays, something   
   Java programmers take for granted), and when I soon realized that Forms 9i   
   was just a Java applet and wrapper for client-side PL/SQL, I switched to   
   JDeveloper and haven't looked back.  One of the benefits I find that works   
   for me is the ability to develop/debug/test Java code completely   
   client-side, then move it to stored procedures with a few minor changes, or   
   move the code to a middle-tier... or wherever... the portability and   
   flexibility is what I like.  What people seem to balk at is the bit of work   
   it takes converting back and forth between Java types and PL/SQL types...   
   not a big issue really.  A someone who has tried both PL/SQL and Java... I   
   can honestly say I will not use PL/SQL unless I absolutely have to, but I   
   will acknowledge that Java can create huge messes in the wrong hands.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)