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."
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.
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.
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.
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
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?
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.
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.
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