Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Rob Conery's critique of MySQL?



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.

> 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.


> 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.

> 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.

> One of my favorite constructs is an XML or JSON column in a table.
> How is this not an object?

This demonstrates my point. If tables were superior to objects then
there would be no benefit to stuffing XML or JSON into table cells.
It's great that Oracle, et.al., provide means of doing it but you're
still constrained by the relational model. They're not really nested if
they're columns in a table. 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.

> 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. The only requirement for the engine is to be
8-bit clean.  This goes for any storage system, not just database
engines.


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.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org