Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: New trend in modern IT consultancy - use your relational database as flat file

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

From: Nuno Souto <wizofoz2k_at_yahoo.com.au>
Date: 14 May 2003 17:31:13 -0700
Message-ID: <73e20c6c.0305141631.701ffb4b@posting.google.com>


rainyday333_at_hotmail.com (Jaan Marck) wrote in message news:<cf59f633.0305141000.57c26bb5_at_posting.google.com>...

Thanks for your point of view on this matter, Jaan. Much appreciated.

> time. Software companies, though, try to ensure their product can run
> on several (if not all) major databases. They will try harder to make
> their code portable across databases.

But the bottom line is: there is nothing new in this wish. It's been in the software maker agenda for the last 20 or so years that I can think of. That's why the market went for relational and open Unix solutions in a big way about 15 years ago: combined, they provide the best technical solution for portable application software.

The techniques used are very well known and well defined and there is no "rocket-science" to them. Isolate the non-portable design/code and port just that to optimal specs. If you need to add non-available functionality in a given platform, then consider not supporting that platform (do a cost analysis:it's surprising how many times this is useful!) or consider rolling your own version out of a commercial or free software library. Once in place, the costs are really minimal.

>
> One good approach to do this, is to recognize the differences
> between RDBMS, isolate them from an architectural point of view
> (separate packages...), and then use the underlying database to the
> maximum potential. When porting, only the RDBMS-dependent parts of
> code need to be changed. This is the approach I prefer.
>

Well, that is the approach that I've seen used *only* for the last 20 years or so. Nothing wrong with it: it works very well and produces reasonable quality applications. Sure, it requires people that know what they are doing, but that is not necessarily a synonym for "expensive" or "non-cost effective".

> Another approach is to use middleware portable across databases and
> hope this will shield your developers from database differences. In my
> experience, this is not always the best solution, as the middleware
> usually uses simplistic techniques to accomplish its tasks, staying
> away from any advanced functionality databases offer. This usually
> leads to slow and unresponsive applications.

This is the "new" Java/Sun-minded approach which will virtually ensure sub-optimal systems in just about EVERY case, with EVERY database and OS. Peoplesoft and SAP pioneered it, then IBM and SUN took over.

Of course, IBM and SUN love and actively promote it! I wonder why. Hint: they both make hardware, of which you need HEAPS to address the major short-comings of this model...

Has anyone actually compared the salary costs of the architects and designers that recommend this model against the ones that recommend the previous model? Because I have: it's a complete fallacy to claim that this model is "magically" cheaper.

Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam Received on Wed May 14 2003 - 19:31:13 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US