| Stefan Finzel 2005-07-24, 10:09 pm |
| Using several DBS (miniSQL, SQLite, Adabas, Oracle, ODBC ...) i found it
very useful to use and support several of them and even change the DBS
on demand within the same application.
All applications have a layer to handle DBS specific stuff based on a
connection identifier. One (an older approach) version was just to
rename (nice tcl feature) procedures and create a few intermediate
procedures to keep procedure calls compatible across two or three
different DBS. Another newer reversible approach is able to change DBS
or even use several DBS parallel.
This was initiated about eight years ago by customer never ending
questions and wishes: "Wouldn't be Oracle be better?" "We have a lot of
Oracle expertise" "We now use mySQL as only database" ...
Well, we all know this?
An intermediate layer surely is not as efficient as code targeted to one
DBS directly. But on the other side it is simple and extensible. E.g.
SQLite implementation took one hour, plus a few more hours as the
quoting was different (it is C-like not SQL-like) and had to be checked,
encapsulated and validated in all client applications.
The drawback is restricting to SQL is required which does often not
allow to use special features of one DBS. Ok, ok for very very special
cases the intermediate layer even has a callback interface to inject DBS
specific needs. But this leads to unnecessary complexity most times.
Nethertheless the basic usage of database and table administration is
available like inserting, updating and deleting records.
If efficieny of this "less common denominator" design would be a problem
it would be even able to optimize by changing some DBS handler from
pure tcl (miniSQL mclient, Postgress pgtcl ...) to C-based
implementation (easily integratable to tcl). But raw tcl meens
compatibility and portabilty. (Please try this using raw perl!).
Through the years i got happy with my database featureless approach and
even adopted it to other programming areas.
The more DBS are supported the more complex is the intermediate layer.
Therefore never have been more than four DBS within this layer at same
time to keep it simple. Before making this layer on my own i was
yearning back to perls generic database interface beast. Now WK's tcldb
was just much too late for me (and others?), and a generic tcl DBI
surely tends to get to complicated like perls.
To get back to the initial topic: TCL can't do as much as Perl
Who really cares?
Each time i remember a genius perl trick solving a tasj/problem, i also
realized, i do not need it, as i am actually programming tcl/tk.
Gerald W. Lester wrote:
> Larry W. Virden wrote:
>
>
>
> While I tend to use three different DBs (Oracle, Sqlite, MySql) any
> given thing I'm coding only tends to be targeted to one of them.
>
> I use Oracle at work.
>
> Sqlite for personal stuff.
>
> MySql for some volunteer work at do (the main third party application
> uses MySql, I'm just doing some data mining stuff on the main
> application's DB).
>
> Thus I find it "better" to use the specific interface because each of
> them has "power features" that are available with the specific interface
> that is not available with the more generic interfaces such as tcldb or
> ODBC.
>
> Also my DB design style varies between them do the features the
> databases do or do not support (yes, the others offer things Oracle does
> not -- although you can accomplish the same thing, just in different
> ways). Thus, unless I want to do "less common denominator" code and DB
> design, I think it is better to use the specific interfaces -- then if
> the DB has to be retargeted I know I have to at least look at both the
> code and DB design.
>
> In the end, it all depends on what your goals are.
>
|