Re: acceptable way to program

From: Haximus <e_at_t.me>
Date: Sun, 20 Feb 2005 18:37:28 GMT
Message-ID: <IN4Sd.14342$NN.11580_at_edtnps89>


"Mark C. Stock" <mcstockX_at_Xenquery .com> wrote in message news:_4GdnUcnXPoxFYXfRVn-iQ_at_comcast.com...
>
> "Haximus" <e_at_t.me> wrote in message news:KEVRd.13245$NN.11844_at_edtnps89...
>>
>> "DA Morgan" <damorgan_at_x.washington.edu> wrote in message
>> news:41d8219f$1_1_at_127.0.0.1...
>>> fishfry wrote:
>>>> In article <IhjBd.5746$6i.1873_at_bignews6.bellsouth.net>,
>>>> "Tom Dyess" <tdyess_at_dysr.com> 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. Received on Sun Feb 20 2005 - 19:37:28 CET

Original text of this message