

If new DBMS technologies are so scalable, why is Oracle still on top of TPC-C? - willvarfar
http://dbmsmusings.blogspot.co.uk/2012/05/if-all-these-new-dbms-technologies-are.html

======
willvarfar
The actual title is >80 chars:

"If all these new DBMS technologies are so scalable, why are Oracle and DB2
still on top of TPC-C? A roadmap to end their dominance."

The "roadmap to end their dominance" is very interesting: they have a new
database model and prototype called "Calvin" that scales well with distributed
transactions...

------
pella
<http://news.ycombinator.com/item?id=3982272>

------
shin_lao
Oracle and DB2 are at the top because no other solution is mature, it does not
mean the ACID transaction approach is the best.

Can they make ACID transactions scale? They make bold claims and I'm afraid it
will be hard to live up to it.

Is it worthwhile to make ACID transactions scale? Perhaps it's more efficient
to switch to a new model for massively parallel processing?

~~~
bunderbunder
For the kind of application that TPC-C models ACID is non-negotiable, plain
and simple.

It's one thing for there to be minor blips in data integrity to happen in the
server's handling Google's search results or a social network's user data. But
in a system that processes financial transactions, a blip in data integrity is
an _accounting error_. An accounting error that could potentially expose the
operator of the database system to serious financial harm or legal liability.

~~~
shin_lao
You assume that a single blip in data integrity will cause functional errors.

I think you can design systems that can fail "in theory", but don't in
practice.

------
elchief
NoSQL is fool's gold

~~~
vampirechicken
I'm convinced that "NoSQL" really means "We found out how flipping difficult
it is to write a decent query optimizer, so we didn't write one. Your on your
own."

Otherwise, I cannot think of a reason to eschew the Standard Query Language as
an interface to one's database product.

