Posted by
Hemos
on from the lock-yer-rows-gentlemen dept.
egerlach writes "All you DB admins out there might be interested to know that MySQL 4.0 has finally been released! It's only 4.0.0 alpha, but you can download it here. You can also check out a full list of changes."
unicode support?
by
Anonymous Coward
·
· Score: 1, Interesting
from this./ articleIn 4.0, to be released in mid-October: 'support for the Unicode character set, the SSL (Secure Sockets Layer) protocol, embedded database links and multitable updates'
but still no where to be seen?
Does this really warrant a 4.0 release?
by
jedrek
·
· Score: 5, Interesting
I hate to be a spoilsport, but does this really warrant a 4.0 release? I don't really see anything in the changelog that would support a 1.+ release. Maybe a.1+, but not a 1.+.
Hm... I keep going over it and see stuff like 'Removed all Gemini hooks from MySQL' or 'New character set latin_de which provides correct German sorting'. The only major things I'm seeing right now are the SSL support, support for UNION and boolean fulltext search.
Am I missing something?
Re:Does this really warrant a 4.0 release?
by
Norny
·
· Score: 2, Interesting
I don't think you're missing anything. What bugs me most is that it seems to me like the Gemini table is a feature *enhancement*, yet they're doing everything they can to *remove* it from the distribution.
I'm waiting till Nusphere releases their copy of 4.0 till I download anything. By then I might have already started looking at PostgreSQL.
Windows Frontend?
by
Anonymous Coward
·
· Score: 2, Interesting
Any idea if anyone is going to release a decent Windows frontend? I must have looked at least a dozen frontends for version 3, and 95% of them fail common usability criteria and all of them are buggier than a shithouse rat.
MySQL officially sanctions 2 clients: MySQLGUI and MyCC. MySQLGUI falls into both categories mentioned above, and MyCC is still in PRE-ALPHA according to SourceForge even though it was opened almost a year ago.
And before anyone replies "Have you tried...", I have exhaustively searched for and evaluated every frontend available on the net, so the likelyhood of a someone suggesting one I haven't tried is very slim.
Re:In other news
by
brunes69
·
· Score: 3, Interesting
I never said it wasn't GPL. I'm just tyring to point out that a much better and more robust open source database already exists, and frankly I do't understand why people would continue to use a product so limited as MySQL (it doesnt even support sub-selects!).
You don't need foreign keys to maintain referential integrity. A proper GUI, among many other things, can enforce this anyway. It is a nice feature, but definitely not needed in a well designed system. Further they slow down performance and I have seen projects where they are not used because of this.
This is a terrible suggestion. Unless you're developing a tiny application that only you will be using, anybody who doesn't use foreign keys is completely incompetent. I know, it sounds harsh, but it's true. Not using foreign keys is like writing an application with just one long main() procedure. A. You're assuming that only one gui and no users will ever access this database. B. If the GUI isn't perfect, your data is garbage. C. It makes future analysis and upgrades very difficult, if not impossible.
These can be nice too, but I personally never use them. They are simply not required in any project I've ever seen. Actually I think views are confusing because they mask the real tables. I think this is a style issue more than anything else, YMMV.
Wow. Views are useful for security, and for performance.
No offense guy, but you know absolutely nothing about databases. You really should not be giving out advice on them. Pick up a BASIC database theory book and read it. When you're done, read it again. You have a lot to learn.
I went to this link, and found the name slashdot's senior mysql guy: Brian Aker (aka krow). Seems slashdot has added code for doing better sql dumps in MySQL. If you recall back a few several hundred/. stories, you might remember that he also hacked out a method to have stored-procedure calls in MySQL. Also take note that when slashdot upgraded to version 2.1 of their infamous slashcode, Brian rewrote the schemas for InnoDB style. I'd say that we slashdot folks will see new toys based on some of this new technology because/. is so entrenched with mysql.
See.......... slashdot really is good for something... =)
-- It isn't a lie if you belive it.
Hot and incremental backup
by
Anonymous Coward
·
· Score: 3, Interesting
got this from the InnoDB Todo list on their webpage. Look closely to the end of this statement:
"Hot and incremental backup: you will be able to backup your InnoDB database with a background process without setting any locks on tables and without disturbing the normal processing of your queries. The backup process makes a consistent copy of the InnoDB database, to which you can apply the MySQL binlog when you need point-in-time recovery.
The backup program will be separate from MySQL/InnoDB, and it will be non-free, with an annual license fee of 250 euros. Please contact Heikki.Tuuri@innodb.com for further information"
Re:In other news
by
SuiteSisterMary
·
· Score: 4, Interesting
You ever read slashdot lately, you go to the home page, and you're not logged in? So you read a story, and you try to change the threshold and sort order, and it either goes to main page, or to a 'recent topics' page, or back to the default view of the story?
That's mySQL having fallen over.
Slashdot, who's admins "reboot the MySQL server" *shudder* to fix things.
-- Vintage computer games and RPG books available. Email me if you're interested.
Re:In other news
by
tzanger
·
· Score: 3, Interesting
*cough cough* slashdot
You're giving/. as an example of a rock-solid stable system? I surely hope you're kidding./. Has fallen up and down more times than I care to remember.
IIRC,/. heavily caches both stories and the front page to avoid load on the MySQL server. Before this was done the crashes were a lot more visible. Now, you just don't see new comments until the cache is refreshed. This is both a good and a bad thing, but it does not show that MySQL works well under load.
/. Also shows its MySQL troubles when you try to log in or change your viewing prefs; if the SQL server is down, you get the threaded (ick) cached page instead of what you want.
here is a phpbuilder test that helps back up my claims.
Re:Proof, please
by
tzanger
·
· Score: 3, Interesting
I find the people here slamming MySQL are often doing so based on their theoretical, rather than practical knowledge. But perhaps you are different. I'd like to see you back up your claim.
Here is a recent (MySQL 3.23.26beta and PGSQL 7.1 CVS pre-beta) benchmark. Now I know that benchmarks are the devil's tools, but he really seemed to try and make it a balanced, true-type of benchmark. It is interesting to look at his 1999 benchmark between the two too, where MySQL appeared faster on simple selects and non -concurrent writes to tables. I forget (and don't see it mentioned) if Tim Purdue actually turned off the fsync action that Postgres leaves on by default. If not, it could have explained some of the slowness of Postgres at that time.
My personal experience with older MySQL is that it is unstable and buggy. We used it for our RADIUS backend for about 3 years and it fell over regularly without much effort. About 18 months ago I replaced it with GNU-RADIUSd and Postgres and -- with four times the load -- it has yet to fail. This wasn't super-high-end stuff either. We're talking about 300 dialup lines with a couple RADIUS daemons making SQL calls to update user logins and time spent when logged out. With MySQL it was 48 lines and a single daemon and I was restarting MySQL so much I wrote a script to do it for me (about five times a week or so).
I am glad to hear that MySQL works for you; chacon son gout, as the French say (when they don't have accents handy). However based on my experience and the experiences of those who at least appear to be doing unbiased benchmarking, and also based on my need for referential integrity, ACID compliance and robustness, MySQL loses. Hell even those using it for pure speed are losing too, since it isn't the fastest, despite what MySQL, Inc. claims.
Re:Transactions, foreign keys
by
jamie
·
· Score: 2, Interesting
I'm not sure what you mean about Bender "dropping the login"... we did rework the cookie system a fair bit for Fry (Slash 2.1/2.2) so I'm guessing that bug is long-fixed.
Most of the errors that bring Slashdot down are because we're really pushing the boundary of MySQL and have been for a while. In the last few weeks the cutting edge has caught up with us so it should be more stable now. Which means of course it's time to go to 4.0 because it wouldn't be Slashdot unless something breaks twice a day.
Stupidity runs rampant in our industry
by
Morocco+Mole
·
· Score: 4, Interesting
Well said! I agree with you!
On my last contract I was unable to convince project leads of the value of transactions. Even though my resume clearly shows 10 years of Oracle and 6 years of SQL Server I couldn't convince a bunch of idiots {with an admitted combined total of SQL Server experience of less than 4 weeks} that being able to transactionally update a patient record and the related information about which medications had been administered was a good idea. Their stated reason for not wanting views, transactions, foreign keys, and stored procedures? "Our database is small - only a thousand or so patients per hospital. Transactions would reduce performance. We don't want to use stored procedures because some day we might want to port the database. What's a view? What's a foreign key?"
So after a few weeks of gently, but fruitlessly, trying to explain that stored procedures and views will guarantee the performance you want, that foreign key constraints and transactions will guarantee the integrity that your medical device database must have - I finally couldn't take it anymore.
So one day in a meeting I said: "Can a patient be hurt if a medication is administered twice? What if the power goes down while updating a patient's treatment record and information about a treatment is lost?"
"Yes a patient could be harmed by duplicate treatments, but that won't happen..."
So I said: "I cannot help you..." And I walked off the gig. I dunno what came of that project but I did hear from a friend that 6 months later they had a GUI that featured several screens that took between 30 seconds to a full minute to bring up one screenful of information. People just don't get the golden rule: Code defensively and keep your business logic as CLOSE to the disk as you can! There are alot of astoundingly ignorant people out there and you just can't stop them all...
Slashdot Mirror
from this ./ article
In 4.0, to be released in mid-October: 'support for the Unicode character set, the SSL (Secure Sockets Layer) protocol, embedded database links and multitable updates'
but still no where to be seen?
I hate to be a spoilsport, but does this really warrant a 4.0 release? I don't really see anything in the changelog that would support a 1.+ release. Maybe a .1+, but not a 1.+.
Hm... I keep going over it and see stuff like 'Removed all Gemini hooks from MySQL' or 'New character set latin_de which provides correct German sorting'. The only major things I'm seeing right now are the SSL support, support for UNION and boolean fulltext search.
Am I missing something?
Any idea if anyone is going to release a decent Windows frontend? I must have looked at least a dozen frontends for version 3, and 95% of them fail common usability criteria and all of them are buggier than a shithouse rat.
...", I have exhaustively searched for and evaluated every frontend available on the net, so the likelyhood of a someone suggesting one I haven't tried is very slim.
MySQL officially sanctions 2 clients: MySQLGUI and MyCC. MySQLGUI falls into both categories mentioned above, and MyCC is still in PRE-ALPHA according to SourceForge even though it was opened almost a year ago.
And before anyone replies "Have you tried
I never said it wasn't GPL. I'm just tyring to point out that a much better and more robust open source database already exists, and frankly I do't understand why people would continue to use a product so limited as MySQL (it doesnt even support sub-selects!).
You don't need foreign keys to maintain referential integrity. A proper GUI, among many other things, can enforce this anyway. It is a nice feature, but definitely not needed in a well designed system. Further they slow down performance and I have seen projects where they are not used because of this.
This is a terrible suggestion. Unless you're developing a tiny application that only you will be using, anybody who doesn't use foreign keys is completely incompetent. I know, it sounds harsh, but it's true. Not using foreign keys is like writing an application with just one long main() procedure. A. You're assuming that only one gui and no users will ever access this database. B. If the GUI isn't perfect, your data is garbage. C. It makes future analysis and upgrades very difficult, if not impossible.
These can be nice too, but I personally never use them. They are simply not required in any project I've ever seen. Actually I think views are confusing because they mask the real tables. I think this is a style issue more than anything else, YMMV.
Wow. Views are useful for security, and for performance.
No offense guy, but you know absolutely nothing about databases. You really should not be giving out advice on them. Pick up a BASIC database theory book and read it. When you're done, read it again. You have a lot to learn.
I went to this link, and found the name slashdot's senior mysql guy: Brian Aker (aka krow). Seems slashdot has added code for doing better sql dumps in MySQL. If you recall back a few several hundred /. stories, you might remember that he also hacked out a method to have stored-procedure calls in MySQL. Also take note that when slashdot upgraded to version 2.1 of their infamous slashcode, Brian rewrote the schemas for InnoDB style. I'd say that we slashdot folks will see new toys based on some of this new technology because /. is so entrenched with mysql.
See.......... slashdot really is good for something... =)
It isn't a lie if you belive it.
got this from the InnoDB Todo list on their webpage. Look closely to the end of this statement:
"Hot and incremental backup: you will be able to backup your InnoDB database with a background process without setting any locks on tables and without disturbing the normal processing of your queries. The backup process makes a consistent copy of the InnoDB database, to which you can apply the MySQL binlog when you need point-in-time recovery.
The backup program will be separate from MySQL/InnoDB, and it will be non-free, with an annual license fee of 250 euros. Please contact Heikki.Tuuri@innodb.com for further information"
You ever read slashdot lately, you go to the home page, and you're not logged in? So you read a story, and you try to change the threshold and sort order, and it either goes to main page, or to a 'recent topics' page, or back to the default view of the story? That's mySQL having fallen over. Slashdot, who's admins "reboot the MySQL server" *shudder* to fix things.
Vintage computer games and RPG books available. Email me if you're interested.
*cough cough* slashdot
You're giving /. as an example of a rock-solid stable system? I surely hope you're kidding. /. Has fallen up and down more times than I care to remember.
IIRC, /. heavily caches both stories and the front page to avoid load on the MySQL server. Before this was done the crashes were a lot more visible. Now, you just don't see new comments until the cache is refreshed. This is both a good and a bad thing, but it does not show that MySQL works well under load.
/. Also shows its MySQL troubles when you try to log in or change your viewing prefs; if the SQL server is down, you get the threaded (ick) cached page instead of what you want.
here is a phpbuilder test that helps back up my claims.I find the people here slamming MySQL are often doing so based on their theoretical, rather than practical knowledge. But perhaps you are different. I'd like to see you back up your claim.
Here is a recent (MySQL 3.23.26beta and PGSQL 7.1 CVS pre-beta) benchmark. Now I know that benchmarks are the devil's tools, but he really seemed to try and make it a balanced, true-type of benchmark. It is interesting to look at his 1999 benchmark between the two too, where MySQL appeared faster on simple selects and non -concurrent writes to tables. I forget (and don't see it mentioned) if Tim Purdue actually turned off the fsync action that Postgres leaves on by default. If not, it could have explained some of the slowness of Postgres at that time.
My personal experience with older MySQL is that it is unstable and buggy. We used it for our RADIUS backend for about 3 years and it fell over regularly without much effort. About 18 months ago I replaced it with GNU-RADIUSd and Postgres and -- with four times the load -- it has yet to fail. This wasn't super-high-end stuff either. We're talking about 300 dialup lines with a couple RADIUS daemons making SQL calls to update user logins and time spent when logged out. With MySQL it was 48 lines and a single daemon and I was restarting MySQL so much I wrote a script to do it for me (about five times a week or so).
I am glad to hear that MySQL works for you; chacon son gout, as the French say (when they don't have accents handy). However based on my experience and the experiences of those who at least appear to be doing unbiased benchmarking, and also based on my need for referential integrity, ACID compliance and robustness, MySQL loses. Hell even those using it for pure speed are losing too, since it isn't the fastest, despite what MySQL, Inc. claims.
Most of the errors that bring Slashdot down are because we're really pushing the boundary of MySQL and have been for a while. In the last few weeks the cutting edge has caught up with us so it should be more stable now. Which means of course it's time to go to 4.0 because it wouldn't be Slashdot unless something breaks twice a day.
Well said! I agree with you!
On my last contract I was unable to convince project leads of the value of transactions. Even though my resume clearly shows 10 years of Oracle and 6 years of SQL Server I couldn't convince a bunch of idiots {with an admitted combined total of SQL Server experience of less than 4 weeks} that being able to transactionally update a patient record and the related information about which medications had been administered was a good idea. Their stated reason for not wanting views, transactions, foreign keys, and stored procedures? "Our database is small - only a thousand or so patients per hospital. Transactions would reduce performance. We don't want to use stored procedures because some day we might want to port the database. What's a view? What's a foreign key?"
So after a few weeks of gently, but fruitlessly, trying to explain that stored procedures and views will guarantee the performance you want, that foreign key constraints and transactions will guarantee the integrity that your medical device database must have - I finally couldn't take it anymore.
So one day in a meeting I said: "Can a patient be hurt if a medication is administered twice? What if the power goes down while updating a patient's treatment record and information about a treatment is lost?"
"Yes a patient could be harmed by duplicate treatments, but that won't happen..."
So I said: "I cannot help you..." And I walked off the gig. I dunno what came of that project but I did hear from a friend that 6 months later they had a GUI that featured several screens that took between 30 seconds to a full minute to bring up one screenful of information. People just don't get the golden rule: Code defensively and keep your business logic as CLOSE to the disk as you can! There are alot of astoundingly ignorant people out there and you just can't stop them all...
--Richard