[Discuss] Rob Conery's critique of MySQL?

[richard.pieri at gmail.com (Richard Pieri)]

On 8/2/2012 12:50 PM, Mark Woodward wrote:
> This is incorrect. No system with more than one of anything can
> consistently get O(1). There has to be some way of getting a
> specific

I'll touch on this point down below.


> That is your opinion, you are welcome to have it, but if you want to
> debate, put up some arguments to assert the veracity of your
> assertions. If you question my decisions, that's fine, but make sure
> you back up your statements with facts that can be debated,
> otherwise it is just a personal insult.

The largest example I can think of is the VA Hospital system.  It uses
an object database for record keeping for some 8 million veterans.
Delivered early and under budget, by the way.

A little smaller is Partners Healthcare here in Boston.  My knowledge is
a little out of date on this but they were looking at deploying a system
for over 30K users across all of the hospitals in town.

One that I'm more directly familiar with is Ameritrade.  I watched
Ameritrade's conversion from Oracle to Cache for their customer-facing
applications.  Why?  Because Oracle couldn't keep up with their trading
load.  Billions of transactions per day.  Oracle couldn't keep up; the
database cluster kept crashing.


> You are conflating database structure with nomenclature. Under any
> storage system, there is data management. Classes and inheritance do
> not magically do anything. You must code version migration to
> successive versions. This may be merely pre-initializing member
> variables, but it has to be done none the less.

No, I'm not. It's one of the beautiful things about object databases. 
It's the same as object-oriented programming: you build your classes and 
let inheritance organize data. In the cases where you need to provide 
assistance you incorporate that logic as a method.


>> It's great that Oracle, et.al., provide means of doing it but
>> you're still constrained by the relational model.
> How?

Relational tables.


> How? How does one "nest" in an object store? An object, once
> instantiated, instantiates another object. Why does this not work.
> The object has hierarchical data? That's in the XML/JSON. Any
> generic object management system with any specific object
> implementation needs to work out these relationships.

You don't instantiate two objects; you instantiate an object with a
sub-object as one of its elements.  It's basic OOP design.


> This is nonsense. Seriously. I have a table:

This is my point: you have a table.  The table is a kind of object but
everything in a relational database is defined in terms of or in
relation to tables.  So what you have is not an XML object; it's a table
with an XML object stored in one of its cells.


> The best part is that, in postgresql, I can index on fields within
> the object to find an object based on the value of a property. Can
> your object store do that? No.

Object databases don't need this kind of indexing.  You reference data
by Object.Sub-object.Slot.data.  This is how object databases deliver
consistent O(1) performance.


> Well, yes, I could make a cycle with 5 wheels, but there are
> conventions.

Screw conventions.  If a 5-wheel cycle is what you need to make your
application work better then make a 5-wheel cycle.


> "8-bit clean" you mean the data stream need to be UTF-8, correct?

I mean that if you put arbitrary 8-bit (binary) data in then you must
get the same 8-bit data out.


> Exactly. So what advantage does your data store have over an RDBMS
> when and RDBMS can do anything your data store can do?

Better performance, greater scalability, faster deployment, easier
maintenance, and typically at a lower cost for all of it.


> I don't know about you, but I use a database for my domain DNS
> servers, yes postgresql. Its actually two tables, the domain entry
> table and the hosts table. I have a web administration package for
> it and I use replication to copy changes. It works great.

If I may make a joke: I suppose it is tempting, if the only tool you
have is PostgreSQL, to treat everything as if it were a table.  Which
brings me back to the start:

> Big data has its own issues, this is true. You haven't said how or
> why any one system is better than any other here.

Your DNS system is not proof.  It's confirmation bias.  You have
expertise in deploying PostgreSQL applications and here's an example of
one of your PostgreSQL applications working well.  I have have a flat
text file that I edit with Emacs, and I have a Makefile to validate the
file and generate reverse zones.  It works great and it doesn't require
the overhead of a database and web server.  This is confirmation bias, too.

In reality there is no one true, universal best system.  There are
systems that meet or exceed requirements and those that do not.

-- 
Rich P.