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."
Windows-like version numbers
by
chill
·
· Score: 4, Interesting
This means that whenever it is stable and ready for production, it is going to have a random version number. Not the smartest practice.
It would help if the major stable releases were.0 and not.rnd()
-Charles
--
Learning HOW to think is more important than learning WHAT to think.
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: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.
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)
i am not much of a database expert, but i have used transactions, rollbacks (and commits:) as well as subselects with MySQL 4.1, so please enlighten me: what makes these feature not "proper" in MySQL?
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.
In the spirit of the interesting compatibility version numbering post, informative version numbering is straightforward. Every version of software should be go through alpha, beta and release versions, for each change. When starting to edit the source code, increment the version number first. The number to increment, whether.., is determined by kind of compatibility the change will discard from the previous version: major=GUI/features, minor = data formats / APIs, build/patch = bugfixes. Once the number is first incremented, it is an ALPHA version, for testing/revision within the group (even of one person) that has developed it (any designers or programmers). Once alpha testing is complete within the developer group, whose preconceptions influence their testing, it is a BETA version, for testing outside of the developer group (customers, end users, random taste tests). Once beta testing/revision is complete, when all revision is complete, it is a RELEASE version, for another round of idiot-check retesting, usually by the release team testing with the packaging and distribution tools, with marketdroids given a more serious voice, when they take responsibility for unleashing it on the market. When alpha, beta or release phase revisions change compatibility with the previous version's GUI/features or data formats / APIs, the major or minor version number, respectively, is incremented, and it goes back to alpha testing. So an app might have version numbering like:
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
--
--
make install -not war
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
MySql vs. Postgres
by
Alien_Phreak
·
· Score: 4, Interesting
Hi all,
I keep hearing about all the great god-like features of Postgres....but what exactly can Postgres do that mysql can't? i'm going towards setting up a central database (MySQL) linux server at work which will be accessible via Ms. Access using an ODBC driver from the clients. (ie. client running Msft Access changes data on a mysql database on a linux server, easy enough to use gui and a strong enough backend)
So far, i'm not doing anything out of the ordinary. nothing too complicated database wise. What exactly would be the advantage of using Postgres.
What does it do that mysql can't?
Things broken with MySQL
by
jesterzog
·
· Score: 4, Interesting
One of the biggest problems with MySQL that so many people complain about is that the entire design philosophy is not one that supports data integrity. Take a look at the list of MySQL Gotchas for starters.
The reason that it's satisfactory for slashdot is the same reason that it became popular in the first place. It was one of the first freely available database servers, and it had particularly fast benchmark results for situations that required lots of selects and not many updates. (I might be slightly wrong about the details, so someone correct me if necessary.) The fast-select advantage made it a popular option for websites a few years ago, because they involve just that. Lots of page-views (selects) and not many updates.
On the other hand, the integrity aspect of MySQL makes it a pain to code for. The MySQL credo seems to be that if input doesn't make sense, then try to guess what was meant and don't report it. (eg. Inserting a null instead of reporting an error.) Furthermore, the MySQL parser recognises certain parts of SQL syntax that are ignored, and (again) not reported. Instead, it just doesn't do anything and pretends that it all worked.
So instead of being able to rely on constraints set in the database, as can be done with nearly any other well-used database, it's necessary to put large amounts of integrity-checking code for things as simple as making sure that dates are the correct format. In some ways it's more like a half-built SQL interface to a regular file system than a database, with features for data integrity hacked on here and there if you know how to use them and always use them correctly.
In slashdot's case, don't be surprised if a random comment goes missing every now and again, because the integrity support just isn't there without complicated overhead work that induces possible mistakes. Slashdot can get away with losing bits and pieces of data, but that's not usually the case. If I say that I want to put some data in the database and that it must meet specific rules, it should either put it in or result in an error. MySQL doesn't do this reliably.
MySQL now seems to be living only on it's fast reputation that it had in the past, driven by people who've heard that it's good and it's fast, but don't know the details. By now, other free databases (postgresql in particular) have caught up a lot, and should be preferable in most cases if you're starting from scratch.
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.
Re:For all the PostgreSQL zealots out there...
by
jadavis
·
· Score: 4, Insightful
I have been looking for a long time for a MySQL person to actually say something that bugged them about PostgreSQL, and why they couldn't use it.
When I started using postgresql, at 6.5.3, it was deficient in many ways. Advocates may have tried to hide these deficiencies at the expense of whoever they were advising. But, I never got any sense that the developers did.
I remember a post by someone on the mailing list that asked (and I'm paraphrasing here from memory, so I could be off): "Would you run your payroll system on PostgreSQL?" (implying that he bet his paycheck on postgresql) and a primary developer responded "not on 7.0, but on 7.1 [just released at the time], yes."
I really think that postgresql has moved a long way since that time. It's at 7.4.1 right now, and I I simply haven't heard reports for a long time about any sort of "weirdness". It's a 24/7 system now. Heck, I was running a 7.1.x system for a long time with no problems.
Now, I get the same feeling about hidden issues with MySQL from the advocates of that system. But I actually check up on my facts, and I've decided that I would prefer not to use a database that thinks Feb 31st is a date.
Granted, I understand that the features of PostgreSQL have to develop a track record of actually working. Well, all the things you mention were fixed at least a year ago, and yes, they do work.
I also understand that MySQL works for you. But what I don't understand is why PostgreSQL doesn't work for you. I'm not saying you should switch to postgresql, but I would like to hear of an actual problem someone had using it in the last 12 months (or heck, 24 months) that MySQL solved. What can PostgreSQL possibly do that would attract your attention again?
From my perspective, MySQL has nothing to attract me away from PostgreSQL. MySQL improvements have been suggested many times, and they're working on them. What improvements do you suggest for PostgreSQL?
-- Social scientists are inspired by theories; scientists are humbled by facts.
Slashdot Mirror
This means that whenever it is stable and ready for production, it is going to have a random version number. Not the smartest practice.
.0 and not .rnd()
It would help if the major stable releases were
-Charles
Learning HOW to think is more important than learning WHAT to think.
Who the hell is coding and releasing new versions on Christmas Day? Take a break!!
And who is reading f$%king slashdot on Christmas Day too??
Oh wait.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
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)
i am not much of a database expert, but i have used transactions, rollbacks (and commits :) as well as subselects with MySQL 4.1, so please enlighten me: what makes these feature not "proper" in MySQL?
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.
In the spirit of the interesting compatibility version numbering post, informative version numbering is straightforward. Every version of software should be go through alpha, beta and release versions, for each change. When starting to edit the source code, increment the version number first. The number to increment, whether .., is determined by kind of compatibility the change will discard from the previous version: major=GUI/features, minor = data formats / APIs, build/patch = bugfixes. Once the number is first incremented, it is an ALPHA version, for testing/revision within the group (even of one person) that has developed it (any designers or programmers). Once alpha testing is complete within the developer group, whose preconceptions influence their testing, it is a BETA version, for testing outside of the developer group (customers, end users, random taste tests). Once beta testing/revision is complete, when all revision is complete, it is a RELEASE version, for another round of idiot-check retesting, usually by the release team testing with the packaging and distribution tools, with marketdroids given a more serious voice, when they take responsibility for unleashing it on the market. When alpha, beta or release phase revisions change compatibility with the previous version's GUI/features or data formats / APIs, the major or minor version number, respectively, is incremented, and it goes back to alpha testing. So an app might have version numbering like:
2.3 (released) -> 2.3.1a -> 2.3.1b -> 2.3.1 (released) -> 2.4a -> 2.4.b -> 2.4.1a -> 2.4.2a -> 2.4.3a -> 2.4.3b -> 2.4.4a -> 2.4.5a -> 2.4.5b -> 2.4.5 (released)
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
--
make install -not war
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
Hi all,
I keep hearing about all the great god-like features of Postgres....but what exactly can Postgres do that mysql can't? i'm going towards setting up a central database (MySQL) linux server at work which will be accessible via Ms. Access using an ODBC driver from the clients. (ie. client running Msft Access changes data on a mysql database on a linux server, easy enough to use gui and a strong enough backend)
So far, i'm not doing anything out of the ordinary. nothing too complicated database wise. What exactly would be the advantage of using Postgres.
What does it do that mysql can't?
One of the biggest problems with MySQL that so many people complain about is that the entire design philosophy is not one that supports data integrity. Take a look at the list of MySQL Gotchas for starters.
The reason that it's satisfactory for slashdot is the same reason that it became popular in the first place. It was one of the first freely available database servers, and it had particularly fast benchmark results for situations that required lots of selects and not many updates. (I might be slightly wrong about the details, so someone correct me if necessary.) The fast-select advantage made it a popular option for websites a few years ago, because they involve just that. Lots of page-views (selects) and not many updates.
On the other hand, the integrity aspect of MySQL makes it a pain to code for. The MySQL credo seems to be that if input doesn't make sense, then try to guess what was meant and don't report it. (eg. Inserting a null instead of reporting an error.) Furthermore, the MySQL parser recognises certain parts of SQL syntax that are ignored, and (again) not reported. Instead, it just doesn't do anything and pretends that it all worked.
So instead of being able to rely on constraints set in the database, as can be done with nearly any other well-used database, it's necessary to put large amounts of integrity-checking code for things as simple as making sure that dates are the correct format. In some ways it's more like a half-built SQL interface to a regular file system than a database, with features for data integrity hacked on here and there if you know how to use them and always use them correctly.
In slashdot's case, don't be surprised if a random comment goes missing every now and again, because the integrity support just isn't there without complicated overhead work that induces possible mistakes. Slashdot can get away with losing bits and pieces of data, but that's not usually the case. If I say that I want to put some data in the database and that it must meet specific rules, it should either put it in or result in an error. MySQL doesn't do this reliably.
MySQL now seems to be living only on it's fast reputation that it had in the past, driven by people who've heard that it's good and it's fast, but don't know the details. By now, other free databases (postgresql in particular) have caught up a lot, and should be preferable in most cases if you're starting from scratch.
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