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

From: Tim X <timx_at_spamto.devnul.com>
Date: 15 May 2003 18:56:11 +1000
Message-ID: <87of24eggk.fsf@tiger.rapttech.com.au>

>>>>> "Jaan" == Jaan Marck <rainyday333_at_hotmail.com> writes:

 Jaan> It depends on whether you are an IT shop or a software
 Jaan> company. An IT shop will typically stay with the same database
 Jaan> vendor for a very long time. Software companies, though, try to
 Jaan> ensure their product can run on several (if not all) major
 Jaan> databases. They will try harder to make their code portable
 Jaan> across databases.

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

 Jaan> parts of code need to be changed. This is the approach I  Jaan> prefer.

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

I was just about to post almost exactly the same points. The approach I prefer is to have an additional layer between the database and the application/middleware. This layer is database vendor specific with a standard interface back to the application. All the developers have a standard set of procedures/functions/services to work with and the db vendor layer translates the operation into whatever form suits the database. If you need to support a new vendor's database, yo only have to modify this layer.

The only objections I've had to this is that it means having to maintain multiple database interface modules. this often scares management as they believe this adds significantly to the whole maintenance process. However, my experience has been this is not that bad in reality as the underlying databases tend to be fairly stable and don't change radically - once you have a module established for a particular db, it usually takes only a moderate amount of maintenance which is usually offset by the fact your application performs well with multiple different backends.

I think this is really the only way to go if you have to have portability as a major aim of your application. The only hard part is ensuring your interface to the database driver layer is both sophisticated enough to meet all your needs without becoming too complex. If you get this part right, your application development and maintenance is often a lot easier than attempting to achieve portability by using the lowest common denominator. It also means your developers who work on the application end don't need to understand the backend databases to the same extent - they only really need to know how to utilize your db interface. the developers responsible for maintaining the db interface layer can concentrate on db issues relating to the vendor db they are working with.

Tim

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!

Received on Thu May 15 2003 - 03:56:11 CDT