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.
I have to confess..
by
wackybrit
·
· Score: 3, Interesting
I've been using MySQL 4.1 on a live server (with customers) for two or three months now. I basically wanted subqueries at the time, and so I just upgraded the box with disregard for everyone else;-) Luckily everything worked great! There's a little quirk with Unicode if you play with the character type settings on certain fields (as long as you stay away from Unicode you'll be more than okay). I also occasionally have the server die when given certain lengthy queries, but it comes straight back, and gets on with things.
So, no, it's hardly Oracle, but even MySQL's alpha stuff seems to be reasonably usable, as long as you aren't doing anything too serious. And, as any database expert will tell you, you probably aren't going to be using MySQL for anything that serious anyway. Nice work MySQL.. I'll spare my users from an immediate upgrade to MySQL 5 however.. for now!!
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?
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.
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.
I've been using MySQL 4.1 on a live server (with customers) for two or three months now. I basically wanted subqueries at the time, and so I just upgraded the box with disregard for everyone else ;-) Luckily everything worked great! There's a little quirk with Unicode if you play with the character type settings on certain fields (as long as you stay away from Unicode you'll be more than okay). I also occasionally have the server die when given certain lengthy queries, but it comes straight back, and gets on with things.
So, no, it's hardly Oracle, but even MySQL's alpha stuff seems to be reasonably usable, as long as you aren't doing anything too serious. And, as any database expert will tell you, you probably aren't going to be using MySQL for anything that serious anyway. Nice work MySQL.. I'll spare my users from an immediate upgrade to MySQL 5 however.. for now!!
mogorific carpentry experiments
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?
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.