Re: New trend in modern IT consultancy - use your relational database as flat file

"Jan Gelbrich" <j_gelbrich_at_westfalen-blatt.de> wrote in message news:<b9tlc1$modmp$1_at_ID-152732.news.dfncis.de>...
> Jaan, thank You for these explanations. It seems that app developers have
> similar problems
> like DBAs, to convince some VIP about hard performance facts ...
>
> One question remains to my mind: so far, many apps have been developed the
> way that you decribe,
> following the lowest denominator,
> and consequently people must have seen the imperformant results.
> So, if performance is obviously *not*
> the key point they desire,
>
> how do they explain their unbreakable wish to stay "portable"
> (which is an illusion, BTW: nobody changes the underlying dbs like T-Shirts,
> do they ?)

Oddly enough, when I worked support for a multi-platform multi-database vendor, I would switch them much _more_ often than my T-Shirt! :-) Given the choice, I would prefer the unix/Oracle one, even if it didn't use every bell and whistle. Nowadays though, the customers seem to prefer MS, since it is a lowest common denominator, and bigger shops that would care about newer Oracle features (besides the most basic partitioning) are lost. So far I've managed to stay Oracle, but we'll see.

Jaan's reply to this post that I'm replying to pretty much hit the nails, although I would add, from a vendor's viewpoint, it's the app that is important. Which is why customers pay vendors. This hasn't changed for a long time.

>
> Maybe I just canīt imagine ...
>
> Jan
>
>
> "Jaan Marck" <rainyday333_at_hotmail.com> schrieb im Newsbeitrag
> news:cf59f633.0305140629.1ffdb1d5_at_posting.google.com...
> > I'm a Java architect and a *long* time db architect. Let me present a
> > different point of view on this.
> >
> > I have architected commercial applications using different database
> > systems (DB2, DB2/MVS, SQLServer, Oracle), and I know databases very
> > well. However, when when developing a commercial software application,
> > the company will often require that all database access code is to be
> > written such that the application can be ported. I tried *so many
> > times* to explain that the portable part is only about 5% of the
> > database, but to no avail. Just between Oracle, SQLServer and DB2, I
> > tried to explain the differences in locking models, in the stored proc
> > languages, in advanced SQL features, in transaction isolation levels.
> > If you want to write any non-trivial code, you are writing unportable
> > code. Take, for instance, using select ... for update for Oracle vs.
> > read locks for DB2. Or the long transactions in Oracle, vs. frequent
> > commmits in DB2.
> >
> > The VP of development usually prevails, arguing mindlessly for
> > 'portability'. It's really hard to argue against the simplistic
> > 'portable is good' argument, especially if the Java Container Managed
> > Persistence stuff is thrown in. The development team is then forced to
> > use the lowest common denominator, which is ANSI 92 SQL. Ugh... No
> > stored proces (not portable), no advanced features.
> >
> > The end result is often not pretty - a non-performant app with reams
> > and reams of simple SQL selects that just makes me want to vomit.
> >

Well, that's what alt.fondle.vomit is for! :-)

Actually, I've been amazed at what some vendors can actually do with simple SQL's, and horrified at others. A well-designed, properly normalized system can actually work pretty good. A system carried over from codasyl... amazing they can work at all. Yuckie-pooie.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/politics/20030515-1449-kennedy-intern.html