MySQL RANT

[markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org (markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org)]

>    Date: Fri, 8 Jun 2007 19:35:40 -0400 (EDT)
>    From: markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org
>    Cc: discuss-mNDKBlG2WHs at public.gmane.org
>
>    > On 6/8/07, markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org <markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org> wrote:
>    >>
>    >> In a professional environment, if you ignore the body of knowledge
> and
>    >> theory about the tool-set to your solution, I maintain you should be
>    >> fired.
>    >>
>    >> Even further, without a very specific reason, the choice of using
> MySQL
>    >> shows a complete lack of understanding about SQL databases, and that
> may
>    >> pass these days for beginners, but not for competent software
> engineers.
>    >
>    > For those of us less enlightened, could you share the key features,
> or
>    > lack of them, that make MySQL a fire-able offense?
>
>    That is sort of the problem, there are plenty of good books on the
>    subject. My one little post can't possibly cover the subject at
>    all. Its frustrating, because none of this stuff is a secret and is
>    part of what most would call "computer science" and engineers go on
>    in complete ignorance.
>
>    Similarly, if a computer science grad said "For those of us less
>    enlightened, could you share the benefits of using a tree or hash
>    table over a standard array?" What would you say?
>
> That it depends upon what you're trying to do.  An array's great if
> you need to iterate over every element and/or randomly access elements
> by numerical index, but it's not so great if you need to search it
> frequently, or your space is sparse, or what have you.  The question
> obviously can't be answered without context, but you're the one who
> made the strong statement, so *you* need to back it up.

Well, *you* just made my point. *You* can discuss the pros and cons
intelligently.

>
> Suppose I said "Even further, without a very specific reason, the
> choice of using an array shows a complete lack of understanding about
> data structures".  Or "Even further, without a very specific reason,
> the choice of using a B-tree shows a complete lack of understanding
> about data structures".  Both of those are nonsense.  You use the
> right tool for the job, and sometimes a simple tool is the right tool
> for the job.

Again, you understand arrays, lists, trees, hash, etc. and can discuss
them intelligently, but can you do the pros and cons of database systems
and how they are designed? This is exactly my point.



>
>    For starters, read up on multi-version concurrency, ACID, query
>    planners, and join strategies. These are the basics of what makes a
>    good database a good database, and MySQL does little of it, and
>    what it does do, it does poorly. That's just the correctness rant.
>
> Well, that really depends upon what you're doing.

I don't agree, obviously.

> Query planners and
> join strategies are nice if your application is going to put heavy
> demands on the relevant parts of the database.  If you have a very
> small database that isn't going to grow very much in size or
> complexity, and you don't need ACID compliance, transactional
> semantics, and all that, what's the problem?

Well, here's the thing, based on technical merit, what makes MySQL a good
decision over something like PostgreSQL? My statement still stands, a
professional makes decisions based on merit and can document the decision
process. Describe *any* process where MySQL seems like a good idea, again,
based on merit.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.