MySQL Discussion

[david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org (David Kramer)]

markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org wrote:
> Except for very limited cases, almost every application that uses
> databases NEED transactions and transaction isolation to function
> properly. In fact, if your system doesn't support transactions, it is
> usually simple luck or lack of concurrency that it works at all.

You have a very narrow view of database applications.  There are quite a
few scenarios where transactions are simply not that important.

Were it not after midnight, I'm sure I could come up with more, but off
the top of my tired brain, ...

- Write-rarely-read-lots data, like config data.

- Where transactions are happening on only one table at a time, so
there's no need to group queries together atomically

- Where the mutiple access and reliability issues are met by some other
design element, like data controlled by a singleton.

> The InnoDB tables are better, but much slower, and any speed you think you
> would be getting from MySQL is lost at the expense of trying to perform
> correctly.

Sometimes speed is more important than correctness.


> Try dropping an index from a large table in MySQL. The index are integral
> with the data storage. So, you lock up the table (even with InnoDB) and
> have to rewrite the table simply for dropping an index. (Create as well!)

Do you write applications that drop their tables' index on a regular
basis?  I don't think I ever have.


> I have had MySQL developers look in wonder as I reduce their queries to
> sub-selects and functions, that improve the performance by at least an
> order of magnitude. Saying "I didn't know you can do that." My response is
> "You can on most real SQL databases." (but can't on MySQL)

Can you give an example?  I agree with Tom that I think some of your
MySQL facts are dated.

> Better databases generally (but not always) perform better and provide the
> tools you don't even know you need.

"Better" is in the eye of the beholder.  Depending on the situation,
"Better" can mean "faster", "more scalable", "more infallable", "low
latency", "cheap", "the devil you know", or "is available with the
desired licensing arrangements".

> I know I come off as a hot head, but pet-peeves are those seemingly little
> things that get under our skin, and MySQL is a pet peeve of mine. It's
> like a recurring nightmare because it is bad, but to explain why it is
> bad, one has to explain why certain algorithms and techniques are good and
> needed. The audience says "Lots of people use MySQL, it can't be that bad"
> and stops listening, but the fact remains there are lots of reasons why it
> is really bad, but they are not reasons easily put in a powerpoint bullet.

I think we've asked for specifics, though, and not gotten them from you,
especially about queries that cannot be done in MySQL.

> 
> Its like trying to explain why Linux is better to a Windows user. "But
> everyone use's Windows." Well, not everyone, there are plenty of people
> who know better.
> 
> For anyone interested, I strongly suggest some research. Knowing about
> databases is just as important as knowing about things like compilers,
> threading, shared libraries, etc. Once you get a handle on the subject
> matter, and play around with an Oracle or PostreSQL, you will NEVER again
> look at MySQL the same way.

You're again assuming that your selection criteria are the one true set
of selection criteria.   Sure, Oracle can outperform MySQL, but if I'm
building a non-for-profit company, am I going to fork over tens of
thousands of dollars for software and licensing for Oracle?


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