Hello Greg,
thanks for the reply. I just answer shortly to a couple of points you
raised.
IMO, RDBMS independence is a useless goal.
Software deployments never wake up on a Thursday, and say, "let's change
our database."
Always, the goal is to store information, and to make the best use of the
subsystem. This means you take advantage of RDBMS specifics. So this
*really* means you're not changing the backend.
The idea is in fact to have a *redundant *system against *RDBMS
specifics failures*.
This means that from *one unique* high level data model you derive
"multiple paths"
*specifically *designed for each different RDBMS.
I have never seen a valid use case for a true, production system needing a
switchable backend.
*In fact, this idea for the proposal stems from the work I did in a
large company, AMADEUS*.
They do have troubles with down time of distributed systems caused by
failures in the RDBMS
layer. In fact, they do loose "millions" of euro's anytime they meet an
uncovered bug
in the RDBMS layer (Oracle, in this case).
I think the same will apply to other large organizations.
Similar API? Sure. But not exactly the same. The best apps will design for
a specific backend, and will need specific API access.
Yes, the idea would have to have *different handlers / managers
specifically *designed
for each *different *RDBMS system.
The proposed concept of query abstraction across "paths" (whatever) goes
even further away from proper app/db design.
The idea would be to have *just one mathematically defined super-model*
from which you
may derive *specific models adapted to each different backend RDBMS*.
Cheers,
-g
Thanks for your thoughts.
Federico
