Orchid XP v8 wrote:
> Darren New wrote:
>> I must admit I have to giggle and shake my head at how many people 
>> doing work on new database technologies try really hard to make it 
>> sound like old database technologies only better.
> 
> Maybe because - you know - the old database technologies are already 
> well-understood?

I think it's more that they're already well-approved. :-) A new swoopy 
database that could store and search terabytes in parallel on disks in 
cities all over the world is going to fall down the first time the DBA 
says "Yes, but is it ACID?"

Much the same way that so many machines in the mid-80's failed to sell 
because people asked "Is it IBM compatible?"

> Have you notied how Intel keep designing these new-fangled 
> super-mega-huper chips... and making them binary-compatible with an 
> ancient non-RISC design from, what, 20 years ago? I mean, a modem Intel 
> Core 2 Duo or something is performing all this out-of-order execution, 
> yet it still goes to extreme lengths to enumate a completely sequential 
> machine with no pipelining.

Yep. Except there, it actually has practical implications. Lots of 
people have binary Intel software they need to run. If you're moving to 
a non-relational database, enforcing the ACID properties aren't 
necessarily an important thing.

For example, is it actually important that every search on the same 
keywords on Google invariable return the same result? Is it OK to update 
the UK indecies an hour later than the US indecies when new web pages 
show up?

Clearly, this isn't appropriate for (say) a bank's ATM network. But 
there are lots of applications where nothing bad happens if there's 
temporary inconsistency.

> It would be a damned site *simpler* for it to not try to do all this 
> emulation. In fact, it would be a lot more *efficient* too. But where's 
> the market in that?

Yeah. Some of the chips were actually RISC chips basically interpreting 
x86 machine code, is my undertanding.

>> It just cracks me up that nobody is willing to say "Yes, we don't have 
>> ACID, and that's a *good* thing sometimes."
> 
> Yes, because everybody loves having the ability to make things 
> unreliable and unpredictable...?

It's not "unreliable and unpredictable". It's just that the consistency 
isn't enforced by the database system.

The "C" in ACID is really important when you have multiple tables 
talking about one entity (which is what the "C" actually means).  But 
when you're entire customer, all his orders and configuration and 
history, are all in one record, enforcing the "C" is much less 
important, because the "A" takes care of it as long as your application 
isn't borked.

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.

Post a reply to this message