Problem Statment : advantage's disadvantage's .... interface's to database ??

                   levaraging ...keeping compatibility cross database compatibility?? 

                   instead of the custom bundled interfaces to each database ??
                   
                   various re-usable interface's (code libraries) that can be derived or compiled.

Opporutnity :

Standard access interface's to the (cli i.e. exec, system, shell-ouput) ....output processing

....output piped to a process pipe ....perl ...php ...various other programing utilities on the shelf...

 ....ability to exploit regexp and pattern ....dissect into rows, columns ...manipulate by populating
a datastructure utilizing arrayies , anonymous hash'es.



  viz. structuring of the code using reference's to anonymous-hash's(simulate a array to be able to traverse...automate 
                          efficiently), judicious-usage-ofscope,populating-variable's with a reference handle to a variable outside the scope ,
                          [ freeing up] the reference-handle's at specific buffer periods ) and vice. versa.


eg : $xyz{@arr}= on the lines of  unix terminfo database addresssing tcup tput

     ability to vary dissect the cli output based on regexp ...say number of character's that determine each column-width in row of data outputted.

     row or data addressing when encoding data into a [anonymous] hash.

     emulating the unix 'awk' utilities data processing capabilities, data-addressing capabilities.

Note: The above problem statement having been encountered in various scenarios
      and detailed in various 'Proof of concepts' as mentioned in 
      
       http://uk.geocities.com/ravivenkatus/projects.pdf
       http://ravishankarkv.tripod.com/projects.pdf
        ....apply appropriate
      'use-case' modeling, rationalize and arrive at a workable and feasible 
       solution both commercially and techinically viable.