There was a lot
of reaction to my recent post about
MySQL at Sabre, most of which I don't have the time or interest to
respond to. Too many people just Don't Get It and Never Will.
But I was inspired to visit the church sign generator and make the image you see with this post. I think it's amusing. :-)
Anyway, life would be so much easier if people stopped trying to think of MySQL in terms of Oracle or PostgreSQL or MSSQL or DB2 or... other database servers. It's none of them. It does many things they do not and doesn't do things they do. It satisfies different needs.
And, finally, those who want to argue that "a real database server should do ________ or ________" don't get very far with me. I don't care what you think a product should do in some abstract general terms. I care about how MySQL fits the needs of people I work with. Often it does. Sometimes it doesn't. And I have little problem figuring out the difference.
But, hey, if you feel like bitching MySQL, I won't try to stop you... But the recovering catholic in me knows that you'll probably go to hell for it.
Posted by jzawodn at November 07, 2003 05:12 PM
Must have missed the furor. MySQL has it's place, and it's a very good place as well.
I just don't think I'll ever understand why these people have such fervent hatred for MySQL. I use MySQL to run a lot of websites on. But I also administer a fairly large Oracle database. I see where each has its strengths. And yet I still prefer MySQL for most things.
Why do you prefer MySQL to Postgres ? I haven't been following the discussion about open-source dbms systems. So.. what are the advantages of MySQL?
I'm a MySQL user because its hard to find hosting with PgSQL, which I prefer because it's more compatible with the SQL standard.
Regards. :)
I'll be the first to admit that I have a bias towards PostgreSQL for db projects. I'll also admit that it isn't always the right tool for every job. In other cases either one could be used. As Jeremy already mentioned, each have different feature sets so they also have different strengths and weaknesses.
It's easy to ignore the strengths of the other when you are used to only using one.
I have some projects that use PostgreSQL and some that use MySQL.
So now we can add this to the list:
FreeBSD vs Linux
Vi vs Emacs
KDE vs Gnome
Perl vs Python|Ruby|PHP
PostgreSQL vs MySQL
Because we hadn't added anything to the 'holy war' list lately :-)
I sometimes find that the people who start these holy wars are never experts in both databases. They use something like MySQL and go "Oh I hate this piece of s*it, it isn't anything like PgSQL! I hate it because it doesn't support doing s*it like this, and it sucks because I don't want to take the f*cking time to learn it."
And thus, they go on a crusade, trying to tell everybody how their database is better.
The last time somebody told me that MySQL sucked, I told him to shove..well that isn't appropriate for the children listening. The guy knew nothing about how MySQL worked, or what it involved. Instead he just wanted to say that it just sucked because he didn't know how to use it.
Anyway, use your own damn database, and i'll use mine. Thats all I say to them and go happily along my way, building my project.
Yahoo finance uses mysql? Good God, I'll take all financial data from that site with a HUGE grain of salt!
Could any of the MySQL users point me to the *best* piece of information about MySQL streghts.
Thanks
> good question, what do they use in hell?
They use mysql at yahoo.
> Could any of the MySQL users point me to the *best* piece of information about MySQL streghts.
Here's the complete list:
<
> EOF
If MySQL were such a hellfire fantastic database, it'd make me a better sandwich. I mean, really, the toast was burnt in a few spots and the lettuce was all wilty.
Granted, Oracle wouldn't make me a sandwich until I bought the $53,000/year Sandwich Development Kit license (which featured an 18 year old kid showing up with a bag of wonderbread) and the Postgres Sandwich API set is still in pre-release, but that's purely beside the point.
I don't hate MySQL - I'm just shocked at how profoundly bad it is. I honestly think that if Microsoft produced this product there would be no end to the bitching about its flaws, but b/c it's open source it is somehow immune from well-deserved criticism.
I also object to those who try to cast this as a religous or zealotous debate. It's not. FreeBSD -vs- Linux is. PostgreSQL -vs- MySQL is not. You just can't compare the two. I don't object to MySQL because it doesn't act just like PostgreSQL; I object to it because it is a horrible SQL database and shows little sign of improving in the future.
It is precisely because I know too much about it and how it works that I object to it. The multiple table types are a horrible idea - the hallmark of the relational model (of which all SQL databases are a pale shadow) is data independence from the physical layer. And at the logical layer, users should not have to worry about things like "Does Table A support transactions or referential integrity?"
But even more distressing is MySQL's penchant for making silent modifications to a database. It will silently convert columns from one type to another, silently truncate integer values, silently create default column values, silently create a MyISAM table if you requested an InnoDB one (in some cases), silently create a primary key, etc. Factor into this mess its horrible consistency checking (e.g. the lack of CHECK constraints and the almost total lack of range checking in the DATE datatype), and you have a disaster waiting for happen.
I don't want to have to write application code that double checks every insert to a numeric column to see if MySQL truncated it silently. That's just asinine to even suggest as correct behavior, yet MySQL forces you to do just this. And this is just one example of it's ridiculous behavior.
Please note that none of these issues arises from thiking of MySQL in terms of any other database. Nor are they a result of thinking what a SQL DBMS should do in abstract, general terms. They're specific examples of unacceptable behavior that leads to high risk of data corruption. In a nutshell, I simply don't trust MySQL to reliably store data and protect its consistency.
I wish the majority of MySQL proponents would admit that they don't want a database, but instead a filesystem with a SQL interface.
Then there's the MySQL prostituters. A lot like crack dealers IMNSHO.
> good question, what do they use in hell?
Hm, good question. After all, their load must be heavier.
What MySQL (or MaxSQL) should become IMHO:
It's fast and light right now, and should remain fast and light. Only ONE feature should be added, the ability to load or compile modular functionality like in Linux.
Want views (or sps or triggers or, transactions or the "make toast" feature...) ? Run make menuconfig and either compile it in or load it as a module.
It would be the ideal database for the multi-db-platform lowest common denominator application vendor (none of whom use stored procedures for example).
Resist the bloat!
Derek, regarding your criticism of MySQL (which is incredibly valid), it will fall on deaf ears. Remember, at one point the creators of MySQL didn't even enforce referential integrity (the only intertable integrity rule that most SQL DB's follow anyway) which you can inspect via this link http://sunsite.univie.ac.at/textbooks/mysql/manual.html#Broken_Foreign_KEY.
If the creators of MySQL made such a resounding failure (mostly because of a lack of DB fundamentals) in not implementing keys, it's mostly cause it's cookbook mode programming, which I'd bet is the case. You visit dbdebunk BTW?
I use both MySQL and postgres for different applications, and I use them both because they both have strengths and weaknesses.
re: derek
i'll disagree with you to a point. thinking that type (and resultant value) coercion is Ebil(tm) is mostly a result of having a rigid view of what an RDBMS should be, the same way static/strong/dynamic/weak typing language zealots deride the languages which use a combination that disagrees with their preference. to me, this coercion isn't useful and, in cases where it's quirky (many), it's slightly annoying. yes, it leads to errors, but only for those who aren't familiar with mysql and only once (unless the person in question is an idiot, in which case all is lost anyway). note that a lot of other rdbmses, notably oracle, have a plethora of quirks of their own.
lack of foreign key constraints is only a problem if you need them. when working with rdbmses that support it, i've often (though not always) found them getting in the way.
this all boils down to the application and the worldview. most of the stuff i work on (very high traffic web apps) use an rdbms mostly as an indexed, persistent datastore - i could easily (and would, if a solution that worked for me were available) replace most of the rdbms usage with a distributed write-back hash table.
this is not true for many, most likely very much not true for you; that does not mean it can't be true for anyone. right tools for the job and all that, provided the person making the judgement call has a good understanding of the job and the criteria.
