[Discuss] Rob Conery's critique of MySQL?

[gaf at blu.org (Jerry Feldman)]

On 08/03/2012 10:51 AM, Richard Pieri wrote:
> On 8/2/2012 10:57 PM, Mark Woodward wrote:
>>> going.  They eventually gave up when Ameritrade wouldn't commit to
>>> replacing the entire cluster with bigger servers.
>> Ahhh Bingo! We have the problem.
>
> Yes.  Relational databases don't scale.  You just keep throwing bigger
> and bigger hardware at them.  That's not scaling.
>
>
>> You are arguing semantics.
>
> I'm arguing storage and retrieval mechanisms.  It's ultimately just
> bits on some kind of media.  What differentiates relational databases
> from object databases is what the two design philosophies say to do
> with those bits.
>
>>> Then why bother with a relational database at all?
>> Who's bothering?
>
> You are.
>
>> This is No-SQL nonsense. The strength of an RDBMS is the man-centuries
>> of work and science embodied in retrieving data. The relational
>> capability is a very powerful tool, sure, but in the end the real
>> science is finding the data you want.
>
> Just because there are man-centuries of work in the field doesn't make
> it the best way to do things.
>
> At this point I don't think there's any point to trying to continue
> this.  We're not debating; we're running around in circles.
>
I would agree. The important issues is (1) how the information is
organized and (2) the speed of retrieval. It does not matter what the
data looks like in physical storage as long as the data is readily
available to authorized people. Many years ago, at a fast food company
in San Antonio we moved from Burroughs to IBM. IBM proposed IMS (Sequel
had not yet been available). IBM's DB was a hierarchical database. I
recommended another database although we had been featured in IBM ads.
The issue was that the company frequently changed its structure where
IBM's DB at the time would have been a straight jacket. The other
company set up a demo on our system and gave the head of HR the ability
to make changes. We went with the other company because their product
and architecture fit our needs and IBM's did not.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90