[Discuss] Rob Conery's critique of MySQL?

[markw at mohawksoft.com (Mark Woodward)]

On 08/02/2012 03:46 PM, Richard Pieri wrote:
> 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.

Not to be snide, but 8 million is not a big number.
>
> 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.
OK
>
> 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.
Well, "billions" of transactions per day should be doable in a cluster. 
If your oracle database is crashing, it is misconfigured. Financial 
transactions are a dangerous thing, you really do need ACID for 
fiduciary responsibility.
>
>
>> 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.
You are avoiding the topic, the "storage system," is separate from the 
implementation of the objects. The objects know how to serialize and 
restore themselves as well as upgrade. The storage and location of 
objects is not involved.
>
>
>>> It's great that Oracle, et.al., provide means of doing it but
>>> you're still constrained by the relational model.
>> How?
>
> Relational tables.
That is not a "how," it is a adjective and a plural noun. One does not 
need to use relations in a database, but one has them if they need them. 
An RDBMS is a tool not some kind of mandate.

>
>
>> 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.
Yes, ok, that is done with the XML/JSON class description. What's the 
problem?

>
>> 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.
You are confusing the SQL language with data storage. In postgreSQL, for 
instance, a "table" is nothing more than file filled with variable 
length objects. Its called a table out of canonical usage. You are 
mistaking a semantic difference with a technical one.

If I said the XML was stored in a binary polymorphic object file and it 
could be retrieved by its ID, would that make a difference? Because, 
that is exactly what is happening. For convenience, we call the the 
polymorphic object file a "table."

>
>
>> 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.
>
Sorry, no. It is either a hash table, or they are hiding the index from 
you. Either way, it doesn't matter because databases have hash indexes.

And if you say that objects don't need that kind of indexing, then you 
miss the real power of database. If you have 8 million objects, say 
patients in a database. How do you find them by social security numbers? 
How about by last name? How about by symptoms?

Information is not a static thing. It needs to be usable to be valuable.


>
>> 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.
Ok, then sure, that's to be expected. What you put into a database is 
what you get out, that is, quite frankly, what a database does. I do not 
understand the point you were trying to make.


>
>
>> 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,
How? Prove it.
> greater scalability,
How? Prove it.
> faster deployment,
How? Prove it
> easier
> maintenance, 
How? Prove it
> and typically at a lower cost for all of it.
PostgreSQL is free. It doesn't get much lower in cost.

>
>
>> 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:
No, I needed a DNS system that could replicate, allow user access, 
managed rights and privileges, etc. I could coble something together, or 
use a package that worked out of the package. It was a no brainer.

>
>> 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.
Not really, the DNS package was part of a bigger project that included 
firewall hole punching, dynamic DNS, VPN, etc. I just used it.
> You have
> expertise in deploying PostgreSQL applications and here's an example of
> one of your PostgreSQL applications working well.
I do have some expertise in PostgreSQL, sure, but I always try to find 
the best tool for the task. I have used SQLite and I have done a fair 
amount of storage systems where an RDBMS is not appropriate.

> 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.
Well, that wasn't acceptable for the task at hand as I have explained.