[Discuss] Rob Conery's critique of MySQL?

[Mark Woodward]

On 08/01/2012 11:09 PM, Richard Pieri wrote:
> On 8/1/2012 9:12 PM, Mark Woodward wrote:
>> Oh no! Don't buy in to the No-SQL nonsense.
>
> I'm not.  NoSQL is a buzzword for a class of high-performance 
> non-relational database designs.  It's not the only non-relational 
> philosophy out there and it's certainly not one that I consider "best" 
> but I'm biased against data loss.
>
>
>> Why don't they scale?
>
> The time taken to perform a query against a table increases roughly 
> linearly with the number of rows in the query and the complexity of 
> the query. 
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)

> This degradation continues until the limits of the hardware are 
> reached.  At that point the whole thing slows to an unusable crawl and 
> maybe the system crashes.  Even Oracle's Exadata frames will crash and 
> burn under sufficient load.
Seriously? How much data are you talking about before it "slows to an 
unusable crawl and maybe the system crashes?"

>
>
>> You say there are more robust, flexible, and scalable ways of storing
>> data. Like what? How is it *not* a "table?"
>
> There are plenty of examples of object-oriented and distributed 
> databases that I could use as examples.  The most common of the former 
> are things like medical records and financial histories.
I actually wrote a DICOM image server using early Postgres95. BTW. Do 
those count as medical records?
>
> Robust: In addition to ACID, object databases can provide versioning 
> of objects within data stores.
Well "versioning" is kind of complex, versioning of the object itself or 
the contents? One of my favorite constructs is an XML or JSON column in 
a table. How is this not an object?
>
> Flexible: Object databases provide for arbitrarily complex data 
> structures.
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'

> Objects can be nested and they can be arranged hierarchically. 
Like XML or JSON, right?

> Classes provide a variety of object types within a database.
A number of RDBMS systems support XML or JSON with native functionality. 
You can even create an index based on an element within an XML or JSON 
stream.

> Objects can even be ordered as rows and columns if you so desire.
OK. We got that.
>
> Scalable: Objects can be addressed directly. 
As in any database, sure. Its just a table.
> Searches and joins aren't needed. 
Unless you need to correlate one item of data with another. An RDBMS 
does not *need* to join, but it *can*.

> This means that object retrieval never takes more than a given amount 
> of time regardless of the data store size.
Yes, its called an index. RDBMS have those. Not only that, you can use 
compound indexes that get you even better performance for complex queries.

> Caveat: there are exceptions to this but they are rare.
Really?
>
> DNS is the most widely-used of the latter.
Yes, and the various root domains are implemented using RDBMS.