Re: Real-life PL/SQL these days ...
- From: RameshGeecee <RameshGeecee@xxxxxxxxx>
- To: sfaroult@xxxxxxxxxxxx
- Date: Tue, 14 Apr 2009 19:09:12 +0530
WOW Stéphane !!!
Well put - the Ponzi phase and all and I definitely feel similarly. I am
not too sure about how long it will take further for this trend to reverse
to a point where the database is given the right role rather than being mere
"store".
Guess its time for the industry to wake up to ideas like Toon's Helsinki
declaration.
Regards,
Ramesh.
On Tue, Apr 14, 2009 at 6:51 PM, Stephane Faroult <sfaroult@xxxxxxxxxxxx>wrote:
> If I can add my 0.02 euros, I have known a time when relational
> databases were hot and sexy and when having "SQL" in the name of your
> company was very trendy. But then, what was selling Oracle were the cool
> features of IAD (SQL*Forms, for the uninitiated) and all those nice
> character screens, in the heydays of the VT220 terminal, that you could
> create so fast compared to plain old Cobol programming. Honestly, I
> don't see much of a difference today. It has always been looks that sell
> (even if after a while you wish you had paid more attention to what
> looks were hiding).
>
> In the debate on thin vs fat database, I feel unambiguously on the fat
> side, although I'd qualify it; I have seen, and still regularly see,
> some really terrible PL/SQL procedures and functions that do nothing for
> the glory of the fat database (and I'm pretty sure that the right hands
> could write something more efficient in any other language); I have also
> seen applications that were storing in the database parts of their
> logic. Whenever I see columns that store serialized Java objects, I feel
> nervous.
> The problem is data vs dynamics. Whenever the application logic (and
> whether it is in the application server or in a PL/SQL package doesn't
> do much of a difference to me) adds no value to what SQL allows to do
> (admittedly more or less easily), you can safely question it. Whenever
> you query the database, what you get back should be reliable data or no
> data. Much of the error processing logic I see in programs could be
> dispensed of. Where most programs fail is in the "delegation" to the
> database. Developers micro-manage their data, when they shouldn't.
>
> Will the trend last? The comparison, these days, may be easy, but I was
> reading in "The Economist" the review of a book exposing the theories of
> Hyman Minsky - saying that there were three phases in economic cycles,
> one were people where borrowing carefully and were able to repay
> interest and capital, one when they were becoming stretched and could
> only repay interest, and a final Ponzi scheme phase were everything
> could hold together only when the prices of assets were permanently
> inflating. Many applications are in a Ponzi phase, and rely heavily on
> Moore's law - or perhaps more subtly on raw hardware power increase
> exceeding what is required to process increasing volumes of data. It
> need not be the case, and the fat database is a clear (and relatively
> easy) way to give an enormous performance boost, and as importantly to
> keep architectures "intellectually manageable". Anything else, sexy or
> not, faces collapse anytime.
>
> Stéphane Faroult
>
>
> Stefan Knecht wrote:
> > "Unless database become sexy and exciting it would be hard for younger
> > professionals to get attracted"
> >
> > Well.... The complexity and architecture of the oracle database
> > kernel is probably the sexiest thing I've come accross in my life so
> > far (thank god I'm single right now or that statement could get me
> > into trouble ;-)
> >
> > I'm a great fan of what toon says and advocates. However, the trend
> > nowadays seems to go in quite the opposite direction with many vendors.
> >
> > What you're describing as being "sexy" (colourful charts and buttons
> > and all that ) is IMHO only the surface. Looks can be deceiving, and
> > in this case they certainly are. Once you start looking underneath the
> > covers of such a "sexy" framework it comes down to being incredibly
> > ugly in most cases, and asking for a slow performance by design.
> >
> > Cheers
> >
> > Stefan
> >
> > =========================
> >
> > Stefan P Knecht
> > CEO & Founder
> > s@xxxxxxxx
> >
> > 10046 Consulting GmbH
> > Schwarzackerstrasse 29
> > CH-8304 Wallisellen
> > Switzerland
> >
> > Phone +41-(0)8400-10046
> > Cell +41 (0) 79 571 36 27
> > info@xxxxxxxx
> > http://www.10046.ch
> >
> > =========================
> >
> >
> > On Tue, Apr 14, 2009 at 7:18 AM, hrishy <hrishys@xxxxxxxxxxx
> > <mailto:hrishys@xxxxxxxxxxx>> wrote:
> >
> > Hi Ramesh
> >
> > I am not a expert here like Toon.
> > But here are my experiences from my career (12 years in Database
> > stuff if that matters)
> >
> > I have realised one thing over these many years databases are not
> > sexy they don't catch the imagination of many young minds.Take for
> > example Jquery and the fancy charts and controls that you can make
> > out of it .
> >
> > It immediately attracts attention or all the new web2.0 stuff you
> > can do these days.
> >
> > Database development is unsexy look at the various amount of
> > frameworks out there that makes the developers life so easier to
> > write queries .Practically every technology out there is trying to
> > lure away the developer from writing database stuff.
> >
> > Ruby on Rails has active record which which is a popular ORM
> > framework which allows the developer to continue working without
> > knowing much about sql and in some cases he would not have to
> > spend worrying about how to join 5-6 tables
> >
> > Microsoft's LINQ,Nhibernate and Entity framework do similar things
> > with Linq you can query almost anything even filesystems,XML
> > active directory etc there is simply no motivation for a Microsoft
> > developer to spend time learning poor unsexy sql.
> >
> > Java folks have Hibernate and ibatis and it can generate a lot of
> > code out straight from the database and HQL queries are easier to
> > grasp and write for the OOP's mindset.
> >
> > Oracle has ADFBC but that is geared more towards the sql savvy
> > developers.
> >
> > OOPS gurus like Martin Fowler have advocated the ORM approach and
> > database independence (someone even said at a conf i attended they
> > don't use constraints in the database nor transactions and that
> > keeps the database fast)
> >
> > Offcourse database approach matters when there is some complex
> > query that needs to be done and performance really matters that
> > when the DBA is approached to tune it up but these are for the
> > 20% of the corner cases.
> >
> > Just my thoughts
> >
> > Unless database become sexy and exciting it would be hard for
> > younger professionals to get attracted
> >
> > regards
> > Hrishy
> >
> >
> >
> >
> >
> >
> >
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
Other related posts:
