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

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 ?)

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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> pagesflames_at_usa.net (Dusan Bolek) wrote in message
news:<1e8276d6.0305120753.54198e31_at_posting.google.com>...
> > Greetings,
> >
> > for last few years I can see a new trend in consulting companies. In
> > the past they pretended that their people have some database
> > knowledge. However, I think that this is too old fashioned and not
> > enough sexy for them. So they started a new era in consultancy.
> > In fact all relational theory is obsolete, DB architect position is
> > obsolete and any other database related stuff is too boring for them.
> > Up to date consultant should be proud that he has no database
> > knowlegde, best applications have generated data model with tables
> > like this (real world example):
> >
> > T08000
> > -------
> > T08000T002005_0: NUMBER
> > T08000T007000_0: NUMBER
> > T08000T005000_0: NUMBER
> > T08000header___: VARCHAR2(4000)
> > T08000footer___: VARCHAR2(4000)
> > T08000T008000_0: NUMBER
> > T08000attribs__: NUMBER
> > T08000methodnam: VARCHAR2(32)
> >
> > Of course there is no referential integrity (foreign keys slow things
> > down and we have all needed checks in our application), no triggers
> > (do not need them all logic runs on app server). Database model is
> > cyborg only readable, but that's no problem any more (you should never
> > access database with anything but our fancy DB access layer written in
> > JAVA). This DB access layer maps objects in application to tables and
> > rows within using some unique identifier, it basically means that all
> > range scanning of objects in database needs to be transfered to bunch
> > of single row querries (no problem at all we have great benchmark
> > numbers from SUN/IBM/HP/COMPAQ/MICROSOFT* test labs - * - check what
> > sounds you best). Developing company doesn't have a single DB
> > specialist (do not need them, just JAVA coders) and database layer has
> > no DB specific parts (our application can run on all database
> > platforms with no changes at all).
> > And on top of it, this approach is usually described as new trend in
> > IT and all previous development not using this madness is called old
> > fashioned or just 70s style.
> >
> > What do you think about this? It seems to me that this trend starts to
> > be very popular in J2EE world. I think one of the main reasons can be
> > that this gaves a JAVA guy with no database knowledge feeling that he
> > is not ignorant, but very progressive in the world full of relational
> > reactionist.
> >
> > --
> > _________________________________________
> >
> > Dusan Bolek, Ing.
> > Oracle team leader
> >
> > Note: pagesflames_at_usa.net has been cancelled due to changes (maybe we
> > can call it an overture to bankruptcy) on that server. I'm still using
> > this email to prevent SPAM. Maybe one day I will change it and have a
> > proper mail even for news, but right now I can be reached by this
> > email.
Received on Wed May 14 2003 - 09:53:20 CDT