Posted by
michael
on from the some-data-loss-inevitable dept.
ulrikp writes "Swedish MySQL AB, makers of the MySQL database, have released an Alpha-version of their flagship, dubbed MySQL 5.0.0. The changesinclude basic support for SQL-99 stored procedures. Please note: Despite the version number, this is an Alpha release, and not for general consumption."
Re:Windows-like version numbers
by
Rosyna
·
· Score: 4, Informative
FWIW, MySQL AB has always used funky version numbers like this. 4.0.0 was alpha, looks like every release of 4.1 is alpha and 5.0.0 is alpha. 5.0.32 might be stable.
Re:Very nice
by
Anonymous Coward
·
· Score: 1, Informative
To name just one: PostgreSQL is free and contains subquries and stored procedures (and much much more). Also it has been using a much more professional approach than MySQL (which has oddities like allowing 2004-02-31 to be stored in a date field)
MySQL is still a database that is growing up. It is of course rock solid and fast (and good for some purpose), but it is missing some of the so called "enterprise" features ("real" replication, performant stored procedures, support from all the enterprise tools ("hot" backup solutions, etc))
It is quite interesting what they are doing with MySQL-Max with seems to be their enterprise solution. They teamed up with SAP DB, an open source database technology that SAP bought from Software AG to tease Oracle a bit. It is based on Adabas D a commercial database that has a "oracle compatibly mode" via ODBC.
It is quite interesting to see a mixture of SAP DB and MySQL united in MySQL-MAX. (Infoworld article)
Re:Very nice
by
sketerpot
·
· Score: 3, Informative
Remember that PostgreSQL is also free, and has a number of very cool features. I'm not telling you which one to use, but do remember that MySQL isn't the first open source database to have those features, nor the only one.
Maybe since it's Christmas day we can't expect people to read the manual.
Transaction support has been available with MySQL since 3.2x - that's over two years ago - you need to check what table type you are using. MySQL 4.x has replciation between master adn slave databases. Using replication you can easily do backups without taking down your live server. MySQL 4.1.1 Does subqueries. MySQL 5 should be where we get database clustering.
Now, if folk want to start criticising MySQL without complaining about these features being absent, that'd be great.
Re:About MySQL
by
IANAAC
·
· Score: 4, Informative
Transaction support has been available with MySQL since 3.2x - that's over two years ago - you need to check what table type you are using.
The reason people continue to say there's no tranaction support is probably because ANY other database out there does not require you to explicitly specify what type of table is needed to actually get transaction support.
I'll get modded as a troll on this one, but honestly, MySQL seems to do things opposite any other DB. The things you mention which are doable (transactions, subqueries) require significant rewrites to port an app to or from MySQL.
Re:About MySQL
by
leviramsey
·
· Score: 2, Informative
There is an overhead to transactions and not every application requires transactions (for instance, a web board). Thus, having the flexibility to use transactions for some tables and not for others is actually a good thing. Use the right tool for the job.
Now if only InnoDB supported all the features of MyISAM...
The things you mention which are doable (transactions, subqueries) require significant rewrites to port an app to or from MySQL.
The only thing you need to do is change a line in the config file and specify the table type when creating the tables. I don't call that a significant rewrite to be honest. A simple search and replace would do it.
Re:Windows-like version numbers
by
chill
·
· Score: 4, Informative
MySQL may be many things, but "slow as hell" has NEVER been a complaint. It is many times faster than other SQL servers -- mainly because of the lack of other features.
MySQL has often been described as more of an SQL-interface to a file system than a database.
--
Learning HOW to think is more important than learning WHAT to think.
Re:Windows-like version numbers
by
Sxooter
·
· Score: 2, Informative
I'll see your SQL server and raise you one Postgresql server. We routinely kick MSSQL server's ass at work, by the way.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:Unlike PostgreSQL
by
Anonymous Coward
·
· Score: 1, Informative
"but the performance under heavy loads plainly sucks."
What are you talking about? PostgreSQL shines under heavy loads and large databases. It's MySQL who chokes on heavy loads and large databases.
Get a clue.
Re:MySQL and PHP legalities
by
realcheese
·
· Score: 5, Informative
How did this get modded up so high? This has been hashed over before and it's not illegal to use them together.
See the PHP FAQ
Re:Very nice
by
Anonymous Coward
·
· Score: 1, Informative
Keep on waiting. These are not real subqueries. Stuff such as SELECT name FROM TABLE_1 WHERE id IN (SELECT eligible FROM TABLE_2) still does not work.
Subqueries, including ones exactly like that, have worked on MySQL since 4.1.0. I even just tested it.
In my opinion, PostgreSQL is the superior database. Many of the features that are "alpha" in MySQL have been in PostgreSQL for years and are very mature. Using MySQL, there are features that I miss that are present in PostgreSQL. I haven't noticed the reverse at all.
However, there are a couple of very good reasons to use MySQL:
Windows support is much better with MySQL than PostgreSQL.
Far more hosting companies support MySQL than PostgreSQL
Personally, I couldn't care less about Windows support, but writing apps for clients that want to host their stuff on an inexpensive shared account makes MySQL the obvious target of choice.
For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 5, Informative
I get so tired of reading all these "MySQL sucks" comments from the PostgreSQL crowd every time there is any mention of the two databases. Well, for whatever reason, this time I feel compelled to comment in return.
First of all, I remember back when I was trying to decide which of the two databases to use for my bicycle touring community website, crazyguyonabike.com, and I heard all the same arguments that MySQL is a "toy" that's simply an SQL interface to a flat file system, and how PostgreSQL was a "real" database with actual transactions, subqueries and so on... but then, digging further into PostgreSQL, I found out about the 8k row size limit, and the requirement to halt everything to do a VACUUM occasionally. That really set me back on my heels - 8k? That's really pathetic. Ok, so they've fixed that in the later versions, and the VACUUM also seems to be bit less blocking now, but still - it left me wondering just what else these zealots were conveniently choosing to forget about when recommending PostgreSQL. How about speed? How about all the anecdotal accounts of corrupted databases (again, probably improved somewhat more recently). What other major limitations are they conveniently neglecting to mention these days? I ask, because these people were making exactly the same noises back in the 8k rowsize limit, blocking VACUUM days as they are now.
Thing is, MySQL works really well right out of the gate for most things that people want to do in real life. Here are a few factoids for you:
MySQL *does* have real transactions. It has for quite some time now - just use the InnoDB table type. And for anyone who whines about this not being the default table - get a life! Choice is good, and I would say that for 99% of applications out there, you just don't need transactions. Go ahead and crucify me for saying this - I don't care. It works for a lot of people, many companies all over the world use it for heavy duty database work. I've used it for four years now, and it has *never* crashed on me, *never* lost any data. I use RAID and backup regularly too, but MySQL is ROCK SOLID.
MySQL is getting all these things like subselects and procedures, just with a different priority to PostgreSQL. So what? Again, I have never missed subqueries, and I have some pretty complex queries in my website. Again, go ahead and flame me, I don't care - it works for me, and it works for a LOT of other people too. Which brings me to another thing:
There is a definite sense of intellectual snobbery and elitism in many of the comments from PostgreSQL fans slamming MySQL. This reminds me of some of the people I used to know back at University - these are people who are so wrapped up in their own little cozy theoretical worlds that anything remotely practical or pragmatic in its approach seems to be extremely threatening. I think this is one of the big reasons for the bile - these people are simply threatened by the fact that MySQL is so popular and so much more used across the world. Could there also be a little tribalism creeping in here? You know, my team vs your team. They just can't seem to understand that BOTH databases work very well and BOTH databases have weaknesses, which BOTH development teams are working very hard to fix and make better. Getting religious about this sort of thing helps nobody. But, I guess, given the fact that Religion is in fact so widespread in the world, this would then also point to there being a somewhat large number of people who are so hung up on their own little certainties and fixed viewpoints that anything else just can't be left to stand. Like the Christian missionaries, they have to have everyone else adhering to THEIR point of view, regardless of the fact that there are, in fact, many "ways" to spiritual enlightenment (or data management). Again: Not everyone needs transactions. Many people just need simplicity and speed, and they get it with MySQL. And you know what, if they want transactions then they can have that too! Th
Re:For all the PostgreSQL zealots out there...
by
Sxooter
·
· Score: 4, Informative
Actually, unless it's changed recently, MSSQL server still has something like a 4k field limit, and Oracle, until version 8, had a row limit of 8k as well, and in version 8 introduced a non-indexable / non-searchable long field, which is still the only place you can store things over 8k.
Also, while you seem to be remembering how badly the Postgresql folks badmouthed MySQL, you seem to be conveniently forgetting the badmouthing that MySQL AB (not the users, the COMPANY) handed out to Postgresql, basically LYING in their online crashme results about Postgresql. While the most aggregious of lies have been removed, and the climate between the MySQL developers adn the Postgresql developers has turned decidedly more civil, there was a time when MySQL, the COMPANY, bad mouthed Postgresql, the community. Remember, there is no company to pay for marketing of Postgresql like the is for MySQL.
Even today, the crashme tests erroneously claim a 16 Meg limit to an insert statement (MySQL's is properly listed as 1 Meg). The reality of the fact on that one is that the buffer MySQL uses to test the database is 16 megs, and when it fills up, the test says "yep, 16 megs is the max." Care to guess what the maximum query size is for Postgresql? Well, there isn't a limit, until the machine runs out of RAM, then SWAP. I.e. no real limit except as declared by your hardware.
There were all kinds of snide and nasty comments about Postgresql in the older MySQL docs, like how code in it wasn't carefully crafted, just tossed in, and how it wasn't well tested.
Those kinds of barbs stung, and there are still a lot of Postgresql users with a chip on their shoulder trying to settle the score.
Postgresql, and MySQL, like every data base has warts. It's just knowing which warts are there so you don't pick the wrong database for the wrong application. In the past, the MySQL party line was that you didn't need the things MySQL was missing, even if you were doing banking style transactions or accounting. That attitude has softened as MySQL has gained both traction and features and the marketing behind it has matured.
What I'd like in MySQL is "per database" settings for things like default table types, ansi compliance (ie. " instead of ` for quoting field names, non-insertion of invalid data etc...) so I could create an HR database that had real relational integrity and enforced it, and didn't allow MyISAM tables, but only innodb.
Postgresql has settings that live "per database" that are quite cool, like "alter database set transaction isolation serializable" and it means that all transactions in THAT database will default to serializable. That kind of per database setting would fix a lot of my problems with using MySQL as a general purpose database.
also, there are ways of making transactions cost VERY little in Postgresql, if that's important, such as putting the xlog on a seperate drive, or even better on a battery backed cache RAID controller, or even disabling FSync. Lately, I'd say Postgresql is an even match for MySQL as a content storage database, and it gets rock solid transactional support as a bonus without me having to worry if I declared my tables properly.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
FYI, the Postgresql Global Development Group does something similar. They release 7.4beta1, 7.4beta2, 7.4beta3, then 7.4rc1, 7.4rc2, etc... Then, after release, they go to 7.4.1, 7.4.2, etc...
The added advantage is that they sort alphanumerically according to the order they were released in.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Remember, Postgresql is a MOVING target.
by
Sxooter
·
· Score: 2, Informative
Congrats on being curious enough to look.
I'll just add to the other comments and say that Postgresql is a moving target, under active development by a very talented team, so while MySQL tries to play catchup, Postgresql moves on ahead as well.
The things coming in the next year or so are: Point in Time Recovery Sub transactions Very low I/O contention vacuuming. Win32 native port Multi-master / multi-slave async replication
In the last year, postgresql has added other key features as well, such as industrial strength synchronous replication (.org uses postgresql with this solution), GiST indexes, ssl/ssh connections, many new procedural languages (R, PHP, python, java), and most importantly, performance improvements.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Slashdot Mirror
FWIW, MySQL AB has always used funky version numbers like this. 4.0.0 was alpha, looks like every release of 4.1 is alpha and 5.0.0 is alpha. 5.0.32 might be stable.
To name just one: PostgreSQL is free and contains subquries and stored procedures (and much much more). Also it has been using a much more professional approach than MySQL (which has oddities like allowing 2004-02-31 to be stored in a date field)
It is quite interesting what they are doing with MySQL-Max with seems to be their enterprise solution. They teamed up with SAP DB, an open source database technology that SAP bought from Software AG to tease Oracle a bit. It is based on Adabas D a commercial database that has a "oracle compatibly mode" via ODBC.
It is quite interesting to see a mixture of SAP DB and MySQL united in MySQL-MAX. (Infoworld article)
Remember that PostgreSQL is also free, and has a number of very cool features. I'm not telling you which one to use, but do remember that MySQL isn't the first open source database to have those features, nor the only one.
Transaction support has been available with MySQL since 3.2x - that's over two years ago - you need to check what table type you are using. MySQL 4.x has replciation between master adn slave databases. Using replication you can easily do backups without taking down your live server. MySQL 4.1.1 Does subqueries. MySQL 5 should be where we get database clustering.
Now, if folk want to start criticising MySQL without complaining about these features being absent, that'd be great.
MySQL may be many things, but "slow as hell" has NEVER been a complaint. It is many times faster than other SQL servers -- mainly because of the lack of other features.
MySQL has often been described as more of an SQL-interface to a file system than a database.
Learning HOW to think is more important than learning WHAT to think.
I'll see your SQL server and raise you one Postgresql server. We routinely kick MSSQL server's ass at work, by the way.
--- It is not the things we do which we regret the most, but the things which we don't do.
"but the performance under heavy loads plainly sucks."
What are you talking about? PostgreSQL shines under heavy loads and large databases. It's MySQL who chokes on heavy loads and large databases.
Get a clue.
How did this get modded up so high? This has been hashed over before and it's not illegal to use them together. See the PHP FAQ
Keep on waiting. These are not real subqueries. Stuff such as SELECT name FROM TABLE_1 WHERE id IN (SELECT eligible FROM TABLE_2) still does not work.
Subqueries, including ones exactly like that, have worked on MySQL since 4.1.0. I even just tested it.
In my opinion, PostgreSQL is the superior database. Many of the features that are "alpha" in MySQL have been in PostgreSQL for years and are very mature. Using MySQL, there are features that I miss that are present in PostgreSQL. I haven't noticed the reverse at all.
However, there are a couple of very good reasons to use MySQL:
Personally, I couldn't care less about Windows support, but writing apps for clients that want to host their stuff on an inexpensive shared account makes MySQL the obvious target of choice.
I get so tired of reading all these "MySQL sucks" comments from the PostgreSQL crowd every time there is any mention of the two databases. Well, for whatever reason, this time I feel compelled to comment in return.
First of all, I remember back when I was trying to decide which of the two databases to use for my bicycle touring community website, crazyguyonabike.com, and I heard all the same arguments that MySQL is a "toy" that's simply an SQL interface to a flat file system, and how PostgreSQL was a "real" database with actual transactions, subqueries and so on... but then, digging further into PostgreSQL, I found out about the 8k row size limit, and the requirement to halt everything to do a VACUUM occasionally. That really set me back on my heels - 8k? That's really pathetic. Ok, so they've fixed that in the later versions, and the VACUUM also seems to be bit less blocking now, but still - it left me wondering just what else these zealots were conveniently choosing to forget about when recommending PostgreSQL. How about speed? How about all the anecdotal accounts of corrupted databases (again, probably improved somewhat more recently). What other major limitations are they conveniently neglecting to mention these days? I ask, because these people were making exactly the same noises back in the 8k rowsize limit, blocking VACUUM days as they are now.
Thing is, MySQL works really well right out of the gate for most things that people want to do in real life. Here are a few factoids for you:
MySQL *does* have real transactions. It has for quite some time now - just use the InnoDB table type. And for anyone who whines about this not being the default table - get a life! Choice is good, and I would say that for 99% of applications out there, you just don't need transactions. Go ahead and crucify me for saying this - I don't care. It works for a lot of people, many companies all over the world use it for heavy duty database work. I've used it for four years now, and it has *never* crashed on me, *never* lost any data. I use RAID and backup regularly too, but MySQL is ROCK SOLID.
MySQL is getting all these things like subselects and procedures, just with a different priority to PostgreSQL. So what? Again, I have never missed subqueries, and I have some pretty complex queries in my website. Again, go ahead and flame me, I don't care - it works for me, and it works for a LOT of other people too. Which brings me to another thing:
There is a definite sense of intellectual snobbery and elitism in many of the comments from PostgreSQL fans slamming MySQL. This reminds me of some of the people I used to know back at University - these are people who are so wrapped up in their own little cozy theoretical worlds that anything remotely practical or pragmatic in its approach seems to be extremely threatening. I think this is one of the big reasons for the bile - these people are simply threatened by the fact that MySQL is so popular and so much more used across the world. Could there also be a little tribalism creeping in here? You know, my team vs your team. They just can't seem to understand that BOTH databases work very well and BOTH databases have weaknesses, which BOTH development teams are working very hard to fix and make better. Getting religious about this sort of thing helps nobody. But, I guess, given the fact that Religion is in fact so widespread in the world, this would then also point to there being a somewhat large number of people who are so hung up on their own little certainties and fixed viewpoints that anything else just can't be left to stand. Like the Christian missionaries, they have to have everyone else adhering to THEIR point of view, regardless of the fact that there are, in fact, many "ways" to spiritual enlightenment (or data management). Again: Not everyone needs transactions. Many people just need simplicity and speed, and they get it with MySQL. And you know what, if they want transactions then they can have that too! Th
FYI, the Postgresql Global Development Group does something similar. They release 7.4beta1, 7.4beta2, 7.4beta3, then 7.4rc1, 7.4rc2, etc... Then, after release, they go to 7.4.1, 7.4.2, etc...
The added advantage is that they sort alphanumerically according to the order they were released in.
--- It is not the things we do which we regret the most, but the things which we don't do.
Congrats on being curious enough to look.
I'll just add to the other comments and say that Postgresql is a moving target, under active development by a very talented team, so while MySQL tries to play catchup, Postgresql moves on ahead as well.
The things coming in the next year or so are:
Point in Time Recovery
Sub transactions
Very low I/O contention vacuuming.
Win32 native port
Multi-master / multi-slave async replication
In the last year, postgresql has added other key features as well, such as industrial strength synchronous replication (.org uses postgresql with this solution), GiST indexes, ssl/ssh connections, many new procedural languages (R, PHP, python, java), and most importantly, performance improvements.
--- It is not the things we do which we regret the most, but the things which we don't do.