MySQL 4 Declared Production-Ready

Simprini writes "After absolute ages of testing MySQL 4.0.x in various versions of BETA through GAMMA it looks like MySQL AB finally released MySQL 4.0.12 as ready for prime-time production use. I know my company has been waiting for a long time for this because our customers absolutely refused to use beta releases of this product. Query caching here we come."

Comments

Re:Waiting for maturity

[Osty]

And like 4 years ago I was all for MySQL - "Why the hell do we need stored procedures and triggers? They only slow the database down". This is true, but also this make the software actually reach the client in time by helping you avoid coding extra tons of code for data storage tasks...

Of course, if properly implemented, stored procedures don't slow down the database at all. In fact, stored procedures could easily increase your performance. Proper implementation should include compiling the sql code into something that's more efficient internally for the server. Also, you'll no longer be sending free-form query text to the server, so you're both safer (you can be more strict with what you allow in your strings) and faster (fewer trips to the server and less data sent to the server each time). Not only that, but sprocs let you keep your SQL code separate from your client code, and can allow you to make changes to your business logic without having to touch your client code at all. In short, sprocs are much more useful than just being used for triggers, but unfortunately many MySQLers don't realize what they're missing.

Re:Triggers?

[nontrivial]

Triggers are so overrated. I maintained a huge app that made extensive use of triggers, and after a few years I couldn't go near them without having them explode. Give me MySQL and Perl instead of triggers and stored procedures any day of the week.

What the MySQLer's dont understand

[esconsult1]

The thing that makes Postgresql completely different from MySQL is that it is an *active* RDBMS. By active, I mean that you can set it up so if it gets certain kinds of data, it can operate on that data to create new records, delete records, update other tables etc.

Postgresql has the *intellegence* built in. You can write all sorts of georgous functions to do stuff, especially if, like us, your shop uses several languages... PHP, Perl, Java, Python, C++, etc. Why replicate your data related logic in every client language?

Transaction support and file/record locking are the least of your problems. If you do serious database stuff, at some point, you are *going* to want VIEWS, TRIGGERS, RULES, and STORED PROCEDURES (functions). Having this functionality in the database engine, instead of in your code makes a heck of a lot of difference when the time comes to scale.

Coming from a MySQL backgroud in a multi-language shop, we clearly saw the limitations, and decided to switch the entire database platform over to Postgresql a year ago. We haven't looked back since.

Also, I dont think the developers will be able to make MySQL into an *ACTIVE* database anytime soon, simply because of the current architecture of the system as it is now. They are going to need a heck of a lot of system tables and new code, to accomplish even the simplest stored procedure functionality.

I can see VIEWS being a quick hack, but going beyond that with MySQL as it is, will be quite a stretch, and I don't believe they will finish those features until perhaps the end of next year, as it will require almost a complete rewrite of the base engine IMHO.