Slashdot Mirror
MySQL 4 - Is it Stable?
Shaklee3 asks: "I have been running version 3 of MySQL on the company's website for quite a while now. We recently ran into a problem where we needed the new features of version 4 that uses the UNION clause. We are running FreeBSD 4.6-STABLE and Apache 1.3.26. I know they reccomend not using it in a production environment yet, but from what I hear it is already being used on a few major websites. Does anyone have experience with version 4, and is it stable enough to run on a high traffic site?" If you feel MySQL isn't ready for prime-time, where specifically do you feel it needs improvement?
Having dealt with a lot of databases in a production environment here's my take:
You absolutely don't want to run any database which is designated "not stable" in a production environment.
Or put it another way: If I'm your boss I won't fire you for lacking features of the database. If we decided on this database engine we work around the shortcomings. But I'll have your ass sacked in no time if you install an unstable version of the product and corrupt the database in this process.
If that seems too harsh: You may explain to me the business reason and the risks associated and get it in writing that your management is aware of what's going on and knows of the risks.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Everyone knows that MySQL is not a good choice for heavy lifting, it's much better for lightweight applications where you have a simple database with lots of SELECTs and not much updating. Get used to it. Why must you force it to fit a different mold as well? The reason many of those features were left out is because they resulted in design decisions that slowed the thing down. And yes, MySQL is faster than any other database, except perhaps Oracle when it's finely tuned, but if you have the time and expertise and money for that, chances are MySQL wasn't the database you wanted anyway.
I've used PostgreSQL, a highly SQL compliant DB, and I've used MySQL. I moved to PGSQL because it was a "real RDBMS." After a while, I ended up going back to MySQL because I wasn't using any of the features that made PostgreSQL more desirable. I was writing a fairly simple WWW application.
Many people don't care about setting up a fancy RDBMS, they just want a few tables that they can easily commit to and select from, like a glorified Berkely DB. What's wrong with that?
I am more than a little experienced with "real" RDBMS packages (using MS SQL, DB/2 and Oracle professionally and occasionally personally), and I *believe* that MySQL is somehow "faster".
Why? Because, in general, _it is_. Easier? Easier than Oracle and perhaps Postgres. Toss in some of the third party apps (MySqlFront comes immediately to mind), and it does get quite a lot "easier".
If you are someone who "knows databases", and think you "shouldn't have to worry about the underlying data representation", you are not, in fact, someone who "knows databases". From a MS SQL standpoint: if you have not already married your copy of Delaney's Inside SQL Server (HEAVY on the "underlying data representation"), you do not, in fact, _know_ that RDBMS.
It is such a hugely important area of knowledge when developing (and more particularly, designing) against a particular RDBMS that I am just shy of saying that statement paints you as an idiot.
Views: They're coming. I hate waiting for it, but I can wait.
Triggers: Showing up with Stored Procs? Who knows. Keep your business logic in the middle tier where it belongs and you invalidate 99% of the reasons triggers are used. (Yes, I know there are exceptions.)
Constraints: Business Logic. Middle Tier.
Stored Procedures (oh wait, this wasn't on your list!) This is annoying mostly to people who don't implement a robust middle tier. But it's coming, too.
ANSI compliance: Far more annoying than any of these other things are the few areas where they still have stupid custom functions rather than simply implementing what the standards say.
But, frankly, the situations where the lack of any of these features are lethal to a project are few and far between. (Lack of views and stored procedures for a DB-centric implementation of row-level security, something very few people actually do. Lack of triggers for building complete audit trails that direct DB users cannot sidestep... something else very few actually do...)
Why do I, someone who "knows databases", use and _deploy professionally and commercially_ MySQL?
Because it's fast, stable, and they [seem] to care a whole hell of a lot more about implementing a feature in a manner which is fast and stable rather than implementing it ASAP just so they can add a few marks to their report card.
I have run into two, count 'em, two, areas where MySQL's "lack of features" posed a problem for me. Because I am a _firm believer_ in not tring to make the database do things it is not intended to do, I moved those two things into the very solid middle tier and the problem was solved.
I despised MySQL until this past year or so. It was fairly obviously slanted towards driving websites rather than being a serious RDBMS.
That has changed, is continuing to change and, by all accounts, will continue changing with every release.
It is a pity that some people who "know databases" cannot change their narrow tunnel vision as well.
Now, if you want to argue that MySQL isn't a very good database, that's your business. (I disagree; I make my living as a MySQL DBA, and love it. But you have a right to your own opinion.) But saying that it's not a database because it doesn't have feature x is like saying that a car without cruise control isn't a car.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
"It's amazing to me how many people in the open source community continually try to force mySQL into doing jobs it's clearly not up to"
a ge/909) for instance.
It's amazing to me how often people who make this sort of comment miss the boat so to speak. People stick with MySQL as opposed to switching to PostgreSQL, SapDB,Firebird and the like for the same reason that VB programmers tend to stick with VB, the same reason that Susie Homeuser has stuck with Windows all these years. It has very very little to do with mySQL being "better" than the others. People stick with Mysql because it's quick to learn, easy to setup and reasonably scalable for many applications. People are staying with mySQL because they are comfortable with it, it's already installed and they know how to use it.
Want people to switch to PostgreSQL or (Heaven forbid) *SapDB, then give Joe Admin or Derek Programmer a UI to them that works like Mysql, then make them as easy to install/backup/restore as Mysql.
At the risk of being labled a troll, realize that mySQL will continue to be the OSS DB of choice for the hoards so long as it continues to be the quickest, easiest way to setup a (semi) RDBMS.
*SapDB is a (IMHO) a pile of steaming speghetti code that I would not wish on my worst enemy. Try taking a look at the code (www.sapdb.org) or if you lazy, just read some of the messages on the SapDB Yahoo group (http://groups.yahoo.com/group/sapdb-general/mess
Bugs Bunny was right.
The so-called MySQL benchmark compares MySQL and other databases doing a whole pile of somewhat obscure database functions one at a time. If your database only has one user, and you spend a lot of time truncating tables, then MySQL is probably the correct choice. For a much more realistic benchmark try here. After looking at MySQL's benchmarks I had to conclude that either the MySQL developers are ridiculously naive about real world data loads or that they are being deliberately deceitful. No one cares how a database performs when there is one single user.
MySQL is a fine database if your are creating an appliation that is read intensive and that doesn't need any of PostgreSQL's more advanced features.