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.
I know people really dig MySQL and everything, but seriously, PostgreSQL has all of those features, and it's ready for production use NOW.
Gabriel Ricard
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
3 = Sell support contracts
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.
Why the hype around MySQL when Postgres has all those features ready for primetime.
MySQL is easier to install on a Windows machine is my guess. I know thats the reason my group went with mysql on a project last year. We could not require that our customer installed a Linux (or similar) server.
I really want to use postgresql but i've tried it and its really unfriendly to use. :-)
Maybe i'm dumb but dumb people need databases too
Bush and Blair ate my sig!
Three words: performance performance performance.
A few projects NEED the advanced features PostgreSQL has. Most projects COULD USE the advanced features PostgreSQL has. If you have rockstar programmers who know the difference between saving keystrokes and saving cpu time, and know that shifting logic load to your DB server is generally a BAD thing, you're going to find that you can almost always do things faster (often much faster) in MySQL. Stability is a tough one as its so subjective its hard to compare. I know we use dozens of MySQL servers collectively running tens of thousands of queries per second 24/7 and we haven't had a major issue or lost any data in years.
If performance is key and you aren't into using fancy stuff just because its fancy, you'll want MySQL. If you don't really care about performance, you might like the additional features PostgreSQL offers.
This is not the greatest sig in the world, this is just a tribute.
as much as many may hate to admit not everyone is running linux/unix. MySQL has a native Windows install - you download it and run setup.exe. You can then play with it, develop under windows and deploy elsewhere.
When I went looking for Postgress for Windows all I could find was instructions that involve cygwin.
If it does the job, why switch. If I ever find MySQL can't handle something that I need to do with an app, then I will certainly start looking at Postgres. Right now, I'm not concerned with a lot of the features that postgres has. I'm using it to do simple table queries in small apps. I first started using it because that's what the hosting company had installed on my web server. So I used it. I've been using it ever since because I haven't had any problems with it. - keith
-- Does anybody know where the 'any' key is on the keyboard?
Because I didn't manage to make it work. And boy, I tried. Just to test Postgresql I've spent hours figuring out how to read from it or write/update/delete.
Mysql, on the other hand, has phpMyAdmin.
You've either got more balls, or less real world experience than me. I'm not even *thinking* about using MySQL until all of these new "features" have been tested for at least a year or so. My databases are the kinds of things I play around with.
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
Funny, I use some of those "primetime" databases, and the extra features never 'get in my way'. It's real easy to just not use them when you don't need them. Sometimes I don't use any of the 'fancy' features on some databases, but they are always there, and I end up using them in a lot of cases on things I never would have thought about back when I was MySQL only. When you don't really know what the extra features are/do, it's really easy to believe you don't need them and wouldn't use them. Once you understand them, you can't believe how much easier they make the coding for tons of projects you do.
Many MySQL users prefer it, just because they don't really *know* what it is they are missing.
(This abbicus works fine, It calculates all my numbers for me and I don't need any battery packs, AC power supplies, wires. Hmm, maybe I will try that computer thing just to see what it's like..... OHHHHH! I get it!)
I have used FreeBSD since the linux 2.0 days. FreeBSD was lightyears ahead at the time. I switched back and forth between the operating systems because Linux was more cool and web documentation all touted linux. The Linux distro's were easier to use and more people used them then FreeBSD so I used Linux for awhile as well.
FreeBSD back then had a better VM( still does), better tcp/ip stack( still does), better package management( still does except gentoo), better scsi support, raid card support, volume management, threading, etc.
Its not just the proprietary world where this happens. The most popular opensource apps also reign over technically superior ones.
As mysql gained popularity postgreSQL gained as well. Just not as much. Same is true for FreeBSD. There are a ton of kernel developers for FreeBSD who came from linux and prefered freebsd over linux for a variety of reasons.
Keep in mind Mysql is faster for simple benchmarks and doing things like inserts. Many hackers simply wrote simple perl scripts to see how many inserts a second both could do and found mysql faster. They then falsely assumed it would also be a superior RDBMS.
I heard in Japan the situation is the opposite. If you walked into a bookstore you would only see postgreSQL books and few mysql. Hype is a major factor.
http://saveie6.com/
Use postgres for anything complicated and MYSQL for anything simple, light weight and fast.
/fstab when vi is fine.
Why use openoffice for editing
thank God the internet isn't a human right.
I think you guys presented a good case as for trade-offs.
MySQL - Fast, Well Supported, Good for Simplier Problems
PostgreSQL - Limited Support, Needs more Attention, Suited for Complex Problems
Why "real DBAs" whine
I think the problem is that many DBAs and developers have really come to rely on JOINS, stored-procedures, triggers, etc. I've been using these features very actively for the past 4 years and wondered what I did without them all these years.
In the past year alone, I've written almost 300 stored-procedures, about 1/4 of which are 4 or more pages of code that would have run like a dog has it been written on the client side.
Having done a lot of 2-tiered, 3-tiered, n-tiered design, I've come to realize that the middle tier (business rules) doesn't have to outside the database in Perl code. If you can implement your middle tier inside the database, you'll almost always see a significant performance advantage and not have to worry about writing engine code to handle issues like concurrancy and multiple users.
While MySQL is capable of handling a number of problems, it's very ill-suited for most enterprise business problems.
You should notice that these "Real DBAs" mostly have a fit when people start making claims that MySQL can compete with Oracle. They're afraid some pointy haired boss is going to believe these claims, and is going to ask them to convert thier Oracle databases to MySQL.
As for myself, I see MySQL as a nice step forward as far as performance is concerned, but it's a HUGE step backwards as far as functionality.
In other words, It's a great engine for storing/retrieving lots of data, but it doesn't have the tools for manipulating/querying the data.
For a lot of people, that means not cutting the muster.
Thanks for the comment
"Communism is like having one [local] phone company " - Lenny Bruce
However, having coded in C both for MySQL and PostgreSQL, I have to say that the MySQL docs are clearly better, and that their client library is more feature-rich than PostgrSQL. The MySQL database may lack features, but on the client side it is much easier to get simple things running.