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?

Comments

No!

[CaptainZapp]

Being more of a Postgresql kind of guy, I really can't comment on the virtues of MySQL V4.

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.

Re:MySQL supporters need to learn SQL

[LatJoor]

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?

Re:MySQL supporters need to learn SQL

[Anonymous Coward]

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.