Re: OO and relation "impedance mismatch"

From: Laconic2 <laconic2_at_comcast.net>
Date: Tue, 5 Oct 2004 13:06:51 -0400
Message-ID: <1cydne9eSOpcSf_cRVn-qA_at_comcast.com>


"Marshall Spight" <mspight_at_dnai.com> wrote in message news:e1A8d.205504$3l3.133046_at_attbi_s03...

> Persistence is a useful feature, but not required to qualify as a dbms.
> An all-in-memory, non-persistent SQL engine would still be a dbms.
> It would not be useful for banking apps, sure, but it would have its
> niche. (And it would be fast, eh?)

I don't think persistence is a "yes or no" feature. Rather, it's more like "persistence for how long, and over what events".

If a dbms in memory were not able to guarantee that data would be held for more than 10 microseconds after commit time, I guarantee you that the niche for that dbms would be exceedingly small. If, however, it were not capable of persisting over a power failure, there might still be lots of uses for it.

At the other extreme, I know of some databases that were guaranteed to survive events like the attacks on the twin towers on Sept. 11. And some of those databases were in fact in lower Manhattan, with failover systems in New Jersey. I had no involvment with them on Sept 11, but I noticed some secondary disasters that did NOT happen.

(There's the curious incident of the dog in the night, again).

I agree with you on the fundamental point: a DBMS can be in RAM and still be a DBMS. If the data really needs to be more persistent than RAM can enable, maybe we do our journalling to disk. Received on Tue Oct 05 2004 - 19:06:51 CEST

Original text of this message