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

Why the wish to stay portable, even if it means lower performance? My experience has been with smaller software companies (200-500 employees, usually one flagship product). In these companies, a technical decision is often a result of an interplay between sound engineering practices and a company politics.

  Management has goals that are different from those of architects/developers. If management had its way, things like return on investment, speed of development, developer productivity etc. would be maximized. In other words, a constant race at breakneck speed, and damn the long term consequences. If technical staff had their way, things like quality, maintainability etc. would be maximized. In other words, always do a good job and damn the fire that needs to be fought today.

  A new VP will often look for a way to make a mark. Similarly, a VP of a small startup is looking at a greenfield situation. They will look for things like "portability", "unified architecture", "velocity", etc. These are things that have impact on the bottom line, and that's what matters on the management level.

  Things that technical people want - more education, better tools, more time to do a good job, better requirements - tend to have *negative* impact on the bottom line. They have beneficial long term effect, but their short term impact is not always tangible.

  When management and technical people negotiate their goals, hopefully, a balance is struck. But, the VP may be inexperienced, or forceful, and will simply override the architect. Or, the architect lacks the experience, the communication skills, or simply the backbone to stand up to the VP and make a case for a better architecture. To be fair, I have also seen architects that simply pulled wool over the management eyes, holding job titles such as "Evangelist", and causing untold damage to the company.

  So, often, when the persistence strategy is being decided, it's the weight of the techical architect vs. the weight of the marketing department of the middleware vendor. The architect says "in my experience, it's better to use vendor-specific extensions, but encapsulate them carefully, and use good engineering". The vendor's marketing department will say "our chief architect is a supergenius, and we have XXX customers, and they all have saved YYY dollars, and would you like to go to Hawaii for our technical conference?". And that's how a decision is arrived at.       

"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 ?)
>
> 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 21 2003 - 16:14:44 CDT