incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Federico Strati <fede.str...@gmail.com>
Subject Re: [PROPOSAL] RDBMSSR: RDBMS Software Redundancy Proposal
Date Thu, 24 Jan 2013 09:40:04 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message