[Discuss] Rob Conery's critique of MySQL?

[markw at mohawksoft.com (Mark Woodward)]

On 08/02/2012 12:02 PM, Richard Pieri wrote:
> On 8/1/2012 11:33 PM, Mark Woodward wrote:
>> This is quite wrong. Seriously. If it is a simple "select * from
>> table where val = 'foo;" Then, if there is no index, it will be a
>> table scan. If you execute "create index table_val on table (val)"
>> then you will create an index that will give you (typically) O(log
>> n)
>
> Oracle, et.al. have put a great deal of effort into optimizing
> tables. They've moved from O(n) to O(log n). Still slow. Object
> databases are typically O(1). No relational database can match that.
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 
object from a store.  The only way O(1) can work is if they are stored 
in a large hash table and it is easy to exceed the usable amount of RAM 
in a system with a big enough data store. When that happens you have I/O 
and file system access. Your addressing may look like O(1), but the 
access of an object will likely be O(log N) on file system access.

And yes, Oracle and PostgreSQL do have hash indexing if you want to use it.
>
>> Seriously? How much data are you talking about before it "slows to an
>> unusable crawl and maybe the system crashes?"
>
> That depends on how much hardware you throw at it. Even Oracle's
> Exadata frames will crash and burn if you overload them. It's awfully
> hard to do that but it has happened.
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.
>
>
>> I actually wrote a DICOM image server using early Postgres95. BTW. Do
>> those count as medical records?
>
> I'm not suggesting that you can't build medical applications with
> tables. I am suggesting that there are vastly superior alternatives
> available and questioning your reasons for avoiding them.
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.
>
>> Well "versioning" is kind of complex, versioning of the object itself
>> or the contents?
>
> Either, both, take your pick. Even if the engine doesn't directly
> support versioning it can be implemented with classes and inheritance.
> And you won't suffer the performance hit that you would with replicating
> rows in tables.
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.
>
>> One of my favorite constructs is an XML or JSON column in a table.
>> How is this not an object?
>
> This demonstrates my point. 
Not really.
> If tables were superior to objects then
> there would be no benefit to stuffing XML or JSON into table cells.
That is a silly argument. An RDBMS is meant to handle "data." There is 
no law or practice that says data can't be an object. You are trying to 
assert a conflict that does not exist.

>
> It's great that Oracle, et.al., provide means of doing it but you're
> still constrained by the relational model. 
How?
> They're not really nested if
> they're columns in a table.
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.

> If you used an object database instead of a
> relational database then you could define or modify an appropriate 
> class to encapsulate your XML or JSON objects.
This is nonsense. Seriously. I have a table:

create table myobjects(objectid int, object xml_type);

How is this not (a) valid or (b) legal?

Now, I have used this very structure in Java and PHP web sites using my 
own extension in PHP and XStream in Java for years. The objects manage 
themselves.

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.

>
>> Most RDBMS these days have support for XML or JSON, hell you could
>> serialize binary objects from C or C++ into a blob if you are
>> insistent about binary objects, but none of the "object" databases
>> support binary objects, per se'
>
> Because it's unnecessary. Objects are arbitrary. You can construct
> them however you like. 
Well, yes, I could make a cycle with 5 wheels, but there are conventions.
> The only requirement for the engine is to be
> 8-bit clean. 
"8-bit clean" you mean the data stream need to be UTF-8, correct?
> This goes for any storage system, not just database
> engines.
Exactly. So what advantage does your data store have over an RDBMS when 
and RDBMS can do anything your data store can do?

>
>
> As for DNS, yes, any given zone can be implemented as a table. But the
> whole of DNS isn't a table.  It's a hierarchy of objects.
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.