Slashdot Mirror
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."
We need views. While much of my work can be done in MySQL, until there are views I cannot switch completely from SQL Server 2K. Too many PHB's that need features like views to be overcome. Must control fist-of-death!
The preceding comment has been reviewed and declared to be compliant with HIPPA Phase II regulations.
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.
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.
http://james.nontrivial.org
MySQL used to be significantly faster than PostgreSQL, mainly because it COULD be faster because it didn't have to worry about pesky features like transactions. Now that PostgreSQL has been better optimized and MySQL actually has some (a couple anyway) of these more advanced features, the speed difference is not a factor anymore. Now I think it is just a matter of inertia -- since MySql had such a long run, getting people to change is hard.
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.
Newsfollow.com