Orchid XP v8 wrote:
>>> It seems to me that "BASE" fundamentally requires an ACID-compliant 
>>> database.
>>
>> They describe it in terms of that, but no, it doesn't.
> 
> Sure. Because if you use flat files instead, it's *completely possible* 
> to allow multiple threads to alter the data without completely screwing 
> it up.

Who said anything about flat files or multiple threads? Heck, who said 
anything about files at all? :-)

>>> They're only talking about relaxing consistancy requirements in a few 
>>> key areas. A completely non-ACID database wouldn't function properly. 
>>> (E.g., if the database engine's own metadata became inconsistent, the 
>>> database engine wouldn't be able to read the database any more.)
>>
>> Certainly. But that's not what the "C" means in ACID.
> 
> Didn't say it was. It's more to do with A, really. (And D of course.)

OK. I have no idea what you're talking about here. Certainly if your 
database didn't have A, C, I, or D, then you'd just have a file system that 
can get corrupted. :-)  Like old DOS file systems, say.

>> "I don't corrupt the entire database when the server crashes" isn't 
>> something to brag about, any more than "I don't stall out driving down 
>> the freeway" is a selling point for an automobile.
> 
> I wouldn't mind, but this isn't exactly a trivial thing to guarantee.

It has been a well-solved problem for decades. Not trivial, but even your 
file system manages it nowadays, let alone something designed for crashes.

>> of the billing cycle."  Do you think when the merchant gives you a 
>> refund, you can then go and spend that money at the next store over 5 
>> minutes later?
> 
> I would presume so, yes. (Not that I actually own a credit card - or 
> ever spend money, for that matter...)

Well, you wouldn't think that, for example, the refund would actually have 
to be processed back at the bank before you get credit?

Put it another way: when you mail in the payment for your bill, do you 
expect it to be credited before you get back to your flat from the mailbox? 
Or would you expect it might take a day or two between the time you write 
the check in your checkbook until the time the payment shows up in your 
account at the electric company?

> OK, so if one of the servers is down, you can't do certain things. I'm 
> still not seeing why constraints can't be applied across several 
> databases under normal operating conditions.

Under normal conditions, certainly. But the idea is "this is how you make 
function beta keep working when function alpha is down." If Beta has 
constraints that depend on ALpha being functional, that doesn't work.

Sure, there's no problem if everything's *working*. This is how you make 
google search keep working even when the spiders have crashed. Or how you 
keep ads being served to people even when the system that lets you sign up 
new customers is rebooting.

> Mmm, interesting. (Especially given that Microsoft is industry-renouned 
> for their lack of innovation.)

They do some good stuff at the high end. And it's not really "innovative". 
It's just "100% right".  Whereas most folks are happy with 98% right or so.

> Well, the article in question is just explaining how to implement this 
> stuff "by hand". But I guess it wouldn't be so hard to build a small 
> framework to do it for you. (Read: to do it correctly.)

Right. If you want to do it small, you don't really need the advice. But 
yes, generally you encapsulate that sort of thing in "business logic" 
layers.  Or, if you want to do it generically, you can use something like 
Erlang, which is how they work all that sort of stuff.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message