>> 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.

>> 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.)

> "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.

>> All I can say is, I hope *I* never have to deal with a database so 
>> vast that I have to risk having it give me gibberish from time to time 
>> just so that it's "fast enough".
> 
> It's pretty normal, actually. For example, in the credit card world, 
> "real time" means "we do it every day, instead of waiting for the end 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...)

>> "For constraints to be applied, the tables must reside on a single 
>> database server, precluding horizontal scaling as transaction rates 
>> grow."
>>
>> Um... why?
> 
> A constraint is the "C" kind of consistency. It says you can't update 
> one table without checking another table it's OK. (Foreign Keys are one 
> kind of constraint, but there are lots of others.) If the table with the 
> primary key and the table with the foreign key are on different servers, 
> and the table with the primary key crashes, you can't check when you 
> insert a row into the other table that the constraint is still good.

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.

>> Still, now Amazon's message service (whatever the hell it's called) 
>> makes sense.
> 
> Uh, sorta. More like Microsoft's queue mechanism, which is a lot like 
> Amazon's basic mechanism, except the queue messages can interact with 
> the same transactions that your SQL server and file system are 
> interacting with. You can do things like create a transaction, update 
> some SQL rows, queue a couple messages, and rename a couple of files, 
> then decide you want to roll it all back, and everyone involved will 
> never see the SQL rows, the messages, or the file name changes.

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

>> I do feel, though, that the mechanisms described for processing work 
>> now and restoring consistency later by passing messages, and detecting 
>> when consistency has returned and so forth really ought to be part of 
>> the database engine rather than application code...
> 
> It is. This is how it does things when you have *multiple* database 
> engines, and you want to keep going even when the hardware for some of 
> it has burst into flames.

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.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message