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."
Have they fixed the most serious bug from the 4.x line yet? This makes MySQL versions greater than 3.x utterly useless for many people.
I realize and reaffirm that it is wholly their right to license their software however they like, but would it really be so awful for them to make the client library LGPL?
If you wrote this yourself, I love you. If you stole it from someone else, I love you even more.
Re:MySql vs. Postgres
by
kpharmer
·
· Score: 1, Troll
> 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.
How's this - you'll be using a mature database that has a good implementation of almost all standard database functionality - vs one that has only implemented some of it, and has repeatedly claimed that this standard functionality wasn't necessary.
So, now MySQL is quickly trying to check off all these deficiencies, which include:
- transactions
- unions
- subselects
- triggers
- views
- stored procedures
- stored procedures
- parallelism
- online backups
- replication
- clustering
- etc Some of these have been partially implemented in the 4.1 release, some are now being addressed in this new alpha. Most exist today in postgresql - and are now being incrementally improved.
Who knows? Perhaps they'll do a competant job - on the other hand functionality like 'subselects' isn't something you simply 'check off'. You want a carefully-designed implementation that covers much of the functionality implied here - not just a minimal job.
Not to say that mysql can't do a fabulous job at improving their product in record time. However, I see no reason to give the same company that insisted this functionality wasn't necessary the benefit of the doubt here. Especially when their current stable product has so many unacceptable silent failure modes.
I got bit once by the table type changing back to the default during an ALTER. I don't know if it has been fixed, but beware something like ALTER TABLE DROP COLUMN removing transaction support for those tables.
Also remember transactions silently fail! You need to quadrouple check everything first since you cannot rely on the database to tell you something is wrong.
I simply cannot trust myself to use MySQL for important data. Too many things to double and triple check are *still* correct and properly constrained.
Slashdot Mirror
Have they fixed the most serious bug from the 4.x line yet? This makes MySQL versions greater than 3.x utterly useless for many people.
;)
I realize and reaffirm that it is wholly their right to license their software however they like, but would it really be so awful for them to make the client library LGPL?
Ah, well... just another reason to use a better database instead.
The Free desktop that Just Works
If you wrote this yourself, I love you.
If you stole it from someone else, I love you even more.
> 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.
How's this - you'll be using a mature database that has a good implementation of almost all standard database functionality - vs one that has only implemented some of it, and has repeatedly claimed that this standard functionality wasn't necessary.
So, now MySQL is quickly trying to check off all these deficiencies, which include:
- transactions
- unions
- subselects
- triggers
- views
- stored procedures
- stored procedures
- parallelism
- online backups
- replication
- clustering
- etc
Some of these have been partially implemented in the 4.1 release, some are now being addressed in this new alpha. Most exist today in postgresql - and are now being incrementally improved.
Who knows? Perhaps they'll do a competant job - on the other hand functionality like 'subselects' isn't something you simply 'check off'. You want a carefully-designed implementation that covers much of the functionality implied here - not just a minimal job.
Not to say that mysql can't do a fabulous job at improving their product in record time. However, I see no reason to give the same company that insisted this functionality wasn't necessary the benefit of the doubt here. Especially when their current stable product has so many unacceptable silent failure modes.
I got bit once by the table type changing back to the default during an ALTER. I don't know if it has been fixed, but beware something like ALTER TABLE DROP COLUMN removing transaction support for those tables.
Also remember transactions silently fail! You need to quadrouple check everything first since you cannot rely on the database to tell you something is wrong.
I simply cannot trust myself to use MySQL for important data. Too many things to double and triple check are *still* correct and properly constrained.
Rod Taylor