MySQL 5.1 Improves Performance, Partitioning, Bug Fixes

← Back to Stories (view on slashdot.org)

MySQL 5.1 Improves Performance, Partitioning, Bug Fixes

Posted by CmdrTaco on Saturday April 12, 2008 @03:32AM from the not-sure-that-title-quite-parses dept.

kylehase writes "CIO.com has a writeup about MySQL's 5.1 release planned for next week. Among the enhancements are many bug fixes from 5.0, some of which may increase performance 20% or more, as well as 'partitioning, events scheduling, row-based replication and disk-based clustering.'"

146 comments

It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-12 03:43 · Score: 5, Informative

MySQL has nearly caught up to PostgreSQL in terms of features.

PostgreSQL's Generalized Search Tree (GiST) indexing is still better than anything MySQL has to offer, in terms of performance and capability.

The PostgreSQL OpenFTS full text search engine is another marvel of engineering. It routinely outperforms similar extensions for MySQL in terms of performance, memory usage, and concurrency.

I hope that an upcoming release of MySQL deals with the maximum field size problem. With PostreSQL, there is a max field size of 1 GB. For MySQL, it's a mere 50 MB. For textual representations of certain geographic system data, it's not unusual these days to have individual fields that need to store 500 to 600 MB of data. PostgreSQL handles these fields fine. MySQL fails.
1. Re:It's nearly caught up to PostgreSQL. by IversenX · 2008-04-12 04:13 · Score: 5, Informative
  
  MySQL fails in many other cases, too.
  
  Many people see MySQL as the consistent winner in database benchmarks. I don't mean this in a bad way, but a lot of people are so focused on the performance of MySQL vs. PostgreSQL, that they forget that MySQL is usually only fast for really simple queries.
  
  That would be fine, though, if it weren't for the failing integrity.
  
  In terms of data integrity, PostgreSQL is kilometers ahead of MySQL. With MySQL, I have seen tables get badly corrupted, sometimes even beyond repair(!) if a disk runs full. That's simply unacceptable.
  
  The syntax is also pretty lax. Adding an integer and a string? No problem. String and a float? Sure.
  
  You want a contraint? Sure, it'll accept that query. Will it honour the constraint? Not so much.
  
  Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. This has the potential to create great data loss.
  
  Inserting a row with a primary key value outside the legal range? It'll give no errors, but it also wont insert the row. Instant data loss.
  
  I know it's popular database, but I would probably not recommend MySQL for any project. If you need something lean and fast, try SQLite. Then you _know_ you don't get any type checks and fancy things like that, so you code for it. If you want to proper, free database, go with PostgreSQL. Half-baked is not my kind of tea. I really hope they will work on data integrity in the upcoming releases, but I fear it's not going to happen.
  
  --
  With great numbers come great responsibility!
2. Re:It's nearly caught up to PostgreSQL. by m50d · 2008-04-12 04:26 · Score: 1, Interesting
  
  Probably less than slashdot got for this one
  
  --
  I am trolling
3. Re:It's nearly caught up to PostgreSQL. by locokamil · 2008-04-12 04:35 · Score: 1, Flamebait
  
  No offense intended... but how do you bake tea?
4. Re:It's nearly caught up to PostgreSQL. by chunk08 · 2008-04-12 04:42 · Score: 3, Funny
  
  1. Pick tea leaves
  2. Preheat oven to 400 degrees farenheit
  3. Arrange leaves on baking sheet
  4. Bake until crispy and dry, but not burnt
  5. ???
  6. Profit!
  
  --
  Do away with our corrupt tax code. Support the Fair Tax
5. Re:It's nearly caught up to PostgreSQL. by Splab · 2008-04-12 05:49 · Score: 4, Informative
  
  While I generally agree with you a few points and additions.
  Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. This has the potential to create great data loss.
  
  This is not entirely true. MySQL will revert to MyISAM even though you specifically asked for InnoDB - it will however issue a warning that it is doing so, this of course is a moot point since most application programmers never check for warnings.
  
  And just to feed the flames while we're at it, MySQL will fail to fire triggers on cascading events.
  
  If you got table A and B and C where B references some information in A and C in B all cascades on updates in A, then any update trigger on C (and possibly B) will fail to fire. This is a very big problem if you are using triggers to keep at least some form of consistency.
  
  To top it up most replication services in MySQL are at best flaky, usually they replicate by using the binary log, so if the primary fails you lost the X last seconds/minuttes/hours (depending on setup and load) of transactions. Even if you got the binary log on a GFS you are still in big trouble since the secondary still needs to replay all transactions leading to the failure - I've heard of sites where this was taking minuttes to complete! (This might change in the new version)
  
  Personally I wouldn't touch either PGSQL or MySQL in a mission critical environment, they are very nice toy databases, but when shit hits the fan - and it WILL happen - you need a reliable system with instant failover, which neither database can provide.
6. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-12 06:15 · Score: 3, Interesting
  
  SQLite really isn't that fast and lean though. It's really only good for tiny data stores (in which case you can use RAM instead). If you take the same data and stuff it in the various DB systems you will see SQLite databases are huge compared to MySQL or PostgreSQL (lots of wasted space). Then there is the performance which isn't bad but not better than the other databases.
  
  Don't get me wrong, I like the idea of SQLite. Per-user databases are needed very badly. I just wish SQLite performed better on normal sized data sets.
7. Re:It's nearly caught up to PostgreSQL. by ThwartedEfforts · 2008-04-12 06:46 · Score: 1
  
  I have to disagree, for whatever "normal sized data sets" means. Admittedly anecdotal, but I was once getting unacceptable performance from MySQL on a 400+ million row table with a few simple joins, and it turned out to be faster to export all the data to flat text, import it into an SQLite database and run the entire thing in SQLite. Same hardware, same OS, otherwise idle machine. Unfortunately, there wasn't enough time to investigate exactly what the cause was for the slowdown in MySQL, perhaps it could have used an "optimize table" or two, but the execution plan appeared legit, we just chalked it up to MySQL being comparatively slow to SQLite.
8. Re:It's nearly caught up to PostgreSQL. by segedunum · 2008-04-12 07:20 · Score: 5, Insightful
  
  Personally I wouldn't touch either PGSQL or MySQL in a mission critical environment, they are very nice toy databases
  I hear this refrain from every terrified analyst who ever wants to bring up the dreaded subject of open source databases, and I see no hard evidence for it. Sorry, but my bullshit detector goes into overdrive when I hear the phrase 'mission critical' and 'toy databases'. MySQL has its shortcomings, and has generally been the web database backend of choice (and it powers quite a few large 'mission critical' web sites), but Postgres really has been the open source database that has kicked on. Failover? Mirroring? Clustering? Yer, there are ways and means of doing that pretty well, and I have seen ample evidence that it can be trusted with lots of 'mission critical' tasks.
  
  I've managed to start using Postgres in an organisation that has traditionally been all Oracle. The main reasons are the huge cost involved of additional licensing for additional servers, the incredible amount of DBA assistance that all Oracle installations seem to need and which they don't have the resources to provide and Oracle's incredible ability to suck any system resources you have into a black hole on any system. When any 'mission critical' database has the memory footprint of either MySQL or Postgres, and when it can actually start up in time for the end of the next ice age, give me a call.
  but when shit hits the fan - and it WILL happen - you need a reliable system with instant failover, which neither database can provide.
  An awful lot of people have been waiting an awful long time for that shit to hit the fan - and in the meantime it has cost them an arm and a leg in not only licensing and support costs, but also in a needless waste of system and hardware resources.
9. Re:It's nearly caught up to PostgreSQL. by mindas · 2008-04-12 07:26 · Score: 1
  
  Don't know the specifics of your project, but isn't it better to use a tool that is designed to do the job (FTS in this case)? Lucene is pretty much de facto standard these days, robust and free.
10. Re:It's nearly caught up to PostgreSQL. by Splab · 2008-04-12 08:15 · Score: 4, Interesting
  
  Might want to get your BS detector checked then.
  
  MySQL fails at some very critical points. As I said in previous post it fails to fire triggers on updates.
  Also MySQL believe its better to serve a best effort than a failure - this is probably the biggest NO GO! out there. YOU NEVER EVER do something other than requested in a database. If the transaction model fails you are using no more than an advance file pointer.
  
  Now PG is a very nice database, they got all the right things implemented, and often better than the competition.
  
  PG however does not have any support for scaling, if you want to scale you need some form of middleware to handle it - and currently you have to buy continuent for that - which is a nice product, they however don't support stored procedures and triggers.
  
  And please don't just hit google for PG and scaleability, and come back saying there are all sorts of products out there - most of them are based on triggers and some very bad methods for propergating data - all of them lack the ability to take down primary or secondary server(s) in a running environment and put a new up without interruption in the data flow.
  An awful lot of people have been waiting an awful long time for that shit to hit the fan - and in the meantime it has cost them an arm and a leg in not only licensing and support costs, but also in a needless waste of system and hardware resources.
  
  That line alone tells me you got your head so far up your OSS arse you are seeing pink elephants.
  
  IBM Denmark just went down this week for a whole day, pretty sure their big clients are a bit unimpressed in their failure to bring multimillion installations back online.
  
  If postgres can handle your situation then fine, but in my environment a database failure means everything comes to a grinding halt. And when you promise clients 99.999% uptime you sure as hell need subsecond failover *hint you can't do that with anything that reads binary logs from primary* and zero loss of transactions.
11. Re:It's nearly caught up to PostgreSQL. by Splab · 2008-04-12 08:17 · Score: 0
  
  bloody hell, forgot my point with IBM.
  
  When multimillion dollar installations fails and you are paying for the support + guarantee on uptime you got somewhere to send the bill if shit hits the fan.
  
  What will you do when your PG installation fail? Go on IRC and ask for help?
12. Re:It's nearly caught up to PostgreSQL. by growse · 2008-04-12 09:28 · Score: 5, Insightful
  
  "Phone Sun" I believe is a reasonable answer to your last point. I also believe they're not the only people who do support.
  
  But you're right - anyone who picks MySQL or Postgres to power a super-resiliant mission-critical service is an idiot. And anyone who uses Oracle to power a non-resiliant low to medium load webservice is also usually an idiot.
  
  Tools for the jobs people, tools for the jobs.
  
  --
  There is nothing interesting going on at my blog
13. Re:It's nearly caught up to PostgreSQL. by Splab · 2008-04-12 10:27 · Score: 0
  
  Actually Oracle does come in a "thin" cheap client.
  
  To be honest I haven't checked the new prices on MySQL support, but carrier grade support was very expensive before, and I doubt it has improved with the Sun takeover. They do have support, and it is according to rumors fast, however you don't get that support unless you cough up the money for it.
14. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-12 10:29 · Score: 0
  
  blah blah blah no native replication in postgres
15. Re:It's nearly caught up to PostgreSQL. by merryberry · 2008-04-12 11:10 · Score: 1
  
  bloody hell, forgot my point with IBM. When multimillion dollar installations fails and you are paying for the support + guarantee on uptime you got somewhere to send the bill if shit hits the fan. What will you do when your PG installation fail? Go on IRC and ask for help? Tools for the job; if you are spending millions on software then go with the a company that is going to charge you millions. If you want a kick ass database for free then go with PG.
16. Re:It's nearly caught up to PostgreSQL. by Firehed · 2008-04-12 14:55 · Score: 1
  
  I'm sure you won't like the example, but Facebook is almost entirely powered by MySQL. Granted, it's very heavily modified (at least according to their jobs pages) to provide better support for pretty much everything that'll get mentioned in all of these comments, but they say that most or all of those changes will be released back into the public for future revisions.
  
  I believe that Google also uses MySQL heavily, or at least did at one point. However, that's just some vague recollection and could be totally wrong.
  
  --
  How are sites slashdotted when nobody reads TFAs?
17. Re:It's nearly caught up to PostgreSQL. by Bronster · 2008-04-12 15:17 · Score: 1
  
  I had a bunch of ~200k record databases with about 8 simple tables in them. Indexing data for mail server backups in fact. I was doing lots of indexed queries on said tables, and once the sqlite database hit a certain size it went seek crazy.
  
  By seek crazy I mean that per single _indexed_ query it would perform about 200 seeks on the database file. Multiply that by many thousands of index checks for your typical backup run and it was game over for sqlite.
  
  The machine has 16Gb of memory and a maximum of 30 concurrent backup threads, so I wound up just slurping the entire database into hashes in memory (perl) at startup and doing hash lookups instead. Massively faster.
  
  So yeah, not such a big sqlite fan as I once was. It didn't scale well for me.
18. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-12 16:52 · Score: 0
  
  Tools for the jobs people, tools for the jobs. Precisely why these discussions never go reasonably...
19. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-12 23:34 · Score: 0
  
  I'm sorry, but who dies when Facebook goes down? What "mission critical" service does it provide? It's a website; exactly the type of thing that can get away with using MySQL.
  
  Let me know when a phone company uses it to help route 911 calls. Or an emergency response service starts using it. Or when a national stock exchange switches over.
20. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-13 00:31 · Score: 0
  
  Yes, and PostgreSQL's full-text search engine is designed for full-text search. I suppose next I'll be telling you that obvious troll is obvious.
21. Re:It's nearly caught up to PostgreSQL. by segedunum · 2008-04-13 02:07 · Score: 1
  
  MySQL fails at some very critical points. As I said in previous post it fails to fire triggers on updates.
  If you have a lot of cascading triggers then I'd worry more about what you're doing than how your database handles them. Handling triggers responsibly is important, as you'll never figure out what the hell is happening twelve months from now. That's an application developer's problem, not a DBA's problem, and I wish DBA's would just stay the hell away. If it has to be done for maintenance reasons or something, fair enough, write a trigger or a stored procedure, but if not stay the fuck away please. MySQL doesn't have the best track record on them so don't use it if that bothers you. However, you'd be surprised how often people use triggers when they just shouldn't be. Stored procedures get similar mistreatment from ejit DBAs.
  PG however does not have any support for scaling
  Sorry, but I've seen people 'scale' Oracle not because they actually need it but because Oracle (and other enterprise DBs) is so bad at handling the system resources it consumes that you've got no other option but to get yourself a large cluster. It also tends to be what the Oracle consultants tell you to do. Failover is one thing, which Postgres has fairly decent options for these days, but scaling for the sake of it is quite another. I was surprised how well a Postgres set up scaled though.
  all of them lack the ability to take down primary or secondary server(s) in a running environment and put a new up without interruption in the data flow.
  Not really. There are ways and means around that problem if you have do have it though.
  That line alone tells me you got your head so far up your OSS arse you are seeing pink elephants.
  The only pink elephants I can see are those that Oracle consultants ride in on when they fly in to tell people what it is they should be doing, and scaring them into buying things to patch the deficiencies that Oracle deliberately builds in.
  IBM Denmark just went down this week for a whole day, pretty sure their big clients are a bit unimpressed in their failure to bring multimillion installations back online.
  More fool IBM. Doesn't inspire confidence in enterprise vendors, does it? There are ways and means of making sure that that situation never even occurs and where you don't plan how you're going to bring installations back online first and foremost, but how you keep the thing running indefinitely. That's the biggest failing of 'enterprise' DB consultant thinking. There's a constant attempt to scare people into thinking about this happening, or that happening, when prevention is what matters. Hopefully, open source databases will continue to scare them even more in the future.
  And when you promise clients 99.999% uptime you sure as hell need subsecond failover *hint you can't do that with anything that reads binary logs from primary* and zero loss of transactions.
  I've had Postgres databases over the past few years that have done that, and have provided uptime that is as close to 100% as you can get (albeit with some inexpensive add-on options at times) - network and operating system permitting. In fact, it's always been a network, OS or other outage that has been the cause of any downtime. These are in environments where people really would notice if the database went away for some reason, and very regular backups are kept which are necessary whatever failover options you have.
  
  My main point still stands. I just don't see the reason for the panic some people want to instil over this whole thing. Oracle, and other 'enterprise' DBs, are a waste of time, money, manpower, effort and resources for 99% of the majority.
22. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-13 02:07 · Score: 0
  
  Skype uses PostgreSQL as their backend.
23. Re:It's nearly caught up to PostgreSQL. by segedunum · 2008-04-13 02:16 · Score: 3, Informative
  
  When multimillion dollar installations fails and you are paying for the support + guarantee on uptime you got somewhere to send the bill if shit hits the fan.
  In reality, you have absolutely nowhere to hide and no one else to blame. The downtime still happened, you still have to deal with it and you're the one who picked IBM or whoever. The enterprise vendor doesn't give a fuck because you ponied up the money and you're locked in anyway. The fingers always point at you. Spending other peoples' money in large quantities to cover your ample ass isn't going to help.
  What will you do when your PG installation fail? Go on IRC and ask for help?
  This is another point that gets made by idiot analysts banging on their blogs. Noting the above, that it is always your fault and your responsibility no matter how much money you chuck at an enterprise vendor, you have to have experienced some of the 'enterprise' support from vendors as I have. The caveats on what they will and won't support a lot of the time are unbelievable. In a lot of cases, Google gives you a faster response and more of a hint at the problem - and I've experienced that from everything from databases to server hardware. By the time a consultant arrives, I know more about what's going on than he does.
  
  Also, I think you save a lot of time, money and stress by putting yourself into situations where dependency on emergency enterprise support is minimised. Just a small hint.
24. Re:It's nearly caught up to PostgreSQL. by StormReaver · 2008-04-13 03:22 · Score: 1
  
  "IBM Denmark just went down this week for a whole day, pretty sure their big clients are a bit unimpressed in their failure to bring multimillion installations back online."
  
  That has nothing to do with Open Source in general or PostgreSQL (or even MySQL) in specific. IBM suffered a complete network meltdown, something that no database in the world could have survived. All the many extra thousands of dollars a year paid to big database vendors for automatic failover would have been wasted in this case.
  
  While PostgreSQL needs more built-in scalability features, it is suitable as-is for the vast majority of jobs for which a solid, highly dependable database is needed. I'd estimate that it is suitable for 97-99% of all database jobs, with the aforementioned sites needing subsecond failover being the remaining 1-3% for which PostgreSQL would not be suitable as the primary database.
25. Re:It's nearly caught up to PostgreSQL. by gumbi+west · 2008-04-13 03:51 · Score: 1
  
  Mission critical = required for firm to make maximum profit. What planet are you from?
26. Re:It's nearly caught up to PostgreSQL. by consumer · 2008-04-13 04:18 · Score: 1
  
  PostgreSQL's Generalized Search Tree (GiST) indexing is still better than anything MySQL has to offer, in terms of performance and capability. Since you offer no benchmarks, this is nothing more than FUD.
  The PostgreSQL OpenFTS full text search engine is another marvel of engineering. It routinely outperforms similar extensions for MySQL in terms of performance, memory usage, and concurrency. Same here.
  For textual representations of certain geographic system data, it's not unusual these days to have individual fields that need to store 500 to 600 MB of data. No, that is VERY unusual, and probably a sign of poorly normalized data.
27. Re:It's nearly caught up to PostgreSQL. by consumer · 2008-04-13 04:31 · Score: 4, Informative
  
  With MySQL, I have seen tables get badly corrupted, sometimes even beyond repair(!) if a disk runs full. Perfect, an anecdote witout details or any way to reproduce the claimed problem.
  The syntax is also pretty lax. Adding an integer and a string? No problem. String and a float? Sure. Turn on the strict mode.
  You want a contraint? Sure, it'll accept that query. Will it honour the constraint? Not so much. Turn on the strict mode.
  Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. That would be a fundamental configuration mistake. You would get a warning, and any time you looked at the table definition it would tell you it was a MyISAM table, not an InnoDB one.
  Inserting a row with a primary key value outside the legal range? It'll give no errors, but it also wont insert the row. Instant data loss. Turn on the strict mode. Seriously, this stuff has all been there for YEARS and you have only yourself to blame if you haven't figured it out yet.
  If you need something lean and fast, try SQLite. Give me a break. SQLite is a neat project and great for times when you don't want to bother installing a database daemon (e.g. the music database in Amarok), but its performance is terrible compared to MySQL, especially for concurrent access.
28. Re:It's nearly caught up to PostgreSQL. by TheSunborn · 2008-04-13 04:45 · Score: 1
  
  Have they added indexed fulltext search to InnoDB? Having to choose between indexed full text search and transactions and foreign keys always seem a big problem.
  
  So, yes you can have transactions and you can have indexed fulltext, but you can't have them at the same time.
29. Re:It's nearly caught up to PostgreSQL. by dwarfking · 2008-04-13 05:34 · Score: 1
  
  How about EnterpriseDB?
  
  I would rather get support for my database from an organization dedicated to the database support, rather than an IBM that might provide a DB2 support guy, along with half a dozen sales guys trying to tell you that you need other IBM products to go along with the DB2 database to really have the environment you need.
30. Re:It's nearly caught up to PostgreSQL. by bytesex · 2008-04-13 09:11 · Score: 1
  
  The difference is more that when postgres has a drawback (which it does, many in fact - replication comes to mind, as well as certain configurability options, a reason why you always need a WAL (which you don't) and good caching) it will be plainly stated on their website; so-and-so is still lacking, we're working on it, if you want you can participate by either sending in your comments or implementing this-and-that. If, however, mysql has a drawback (which it has, many in fact) it will state nothing at their website, at first, and when people have been nagging them about it, it will say something like; 'that's never meant to be inside a database, solve it in the client. O by the way, it might be in the next version.'.
  
  --
  Religion is what happens when nature strikes and groupthink goes wrong.
31. Re:It's nearly caught up to PostgreSQL. by zig007 · 2008-04-13 09:53 · Score: 1
  
  "PG however does not have any support for scaling".
  Maybe you should go tell skype that.
  They intend to scale it to handle 1 billion users.
  http://highscalability.com/skype-plans-postgresql-scale-1-billion-users
  
  Also, i have no idea of what you are talking about.
  To scale up database solutions to huge mean to totally rethink how one design the database.
  Using convenient stuff like stored procedures and even worse, triggers, in a large clustered system would be really stupid and a total performance killer. However, if one do design systems like that, one would need someone to blame..
  
  So maybe thats why that isn't a very high priority(for continuent)? Things like that generally belong on application servers which don't mind iterating and algorithmisizing(well you go find a better word then..).
  
  Databases are for set-based operations, and that becomes even more obvious the more the data grows.
  
  Also, achieving a guaranteed zero loss of transactions kind of lessen the need from them in the first place..since the most important aspect of a database transaction is not to commit but its ability to lose itself..wouldn't you say? :-)
  
  And you *always* need middleware to scale databases. It just isn't called middleware by salespeople.
  
  --
  Baboons are cute.
32. Re:It's nearly caught up to PostgreSQL. by Splab · 2008-04-13 09:59 · Score: 1
  
  First of all, I don't use Oracle, so stop telling me why Oracle sucks, I know that.
  I've had Postgres databases over the past few years that have done that, and have provided uptime that is as close to 100% as you can get (albeit with some inexpensive add-on options at times) - network and operating system permitting. In fact, it's always been a network, OS or other outage that has been the cause of any downtime. These are in environments where people really would notice if the database went away for some reason, and very regular backups are kept which are necessary whatever failover options you have.
  How long does your failover take? If you are losing thousands of dollars a minute the system is down, how long will it take before you get shipped out?
  
  If your OS is down, your database is down - this is why we got hot standby, not warm, but truely hot standby options that can take over with subsecond intervals - it costs money, but its needed.
  If you have a lot of cascading triggers then I'd worry more about what you're doing than how your database handles them. Handling triggers responsibly is important, as you'll never figure out what the hell is happening twelve months from now. That's an application developer's problem, not a DBA's problem, and I wish DBA's would just stay the hell away. If it has to be done for maintenance reasons or something, fair enough, write a trigger or a stored procedure, but if not stay the fuck away please. MySQL doesn't have the best track record on them so don't use it if that bothers you. However, you'd be surprised how often people use triggers when they just shouldn't be. Stored procedures get similar mistreatment from ejit DBAs.
  
  Seriously, what the fuck are you raving about?
  
  No fucking way the application programmers will be allowed to ensure data integrity. If you can't figure out what your database is doing after 12 months you haven't documented it properly.
  
  All your ramblings tells me you are an OSS application programmer without the proper background for DB maintenance with some really really bad ideas about what a proper database is, you are most likely drawing your ideas from sites like dailywtf.
33. Re:It's nearly caught up to PostgreSQL. by Splab · 2008-04-13 10:01 · Score: 1
  
  Google has done some work on MySQL.
  
  Those examples are where MySQL does shine. Any web application where you got a factor of 100 or 1000 - even more reads per write, MySQL is a good option.
  
  You can never make a generalization and say this will solve everything. The right tools for the job etc.
34. Re:It's nearly caught up to PostgreSQL. by zig007 · 2008-04-13 10:08 · Score: 1
  
  BTW, didn't mean to dismiss stored procedures totally(they still have some uses, however, the performance gained is just not very significant anymore and sometimes even a loss), was just thinking about when using them in ways that has to include the rest of the cluster.. Sorry 'bout that.
  
  --
  Baboons are cute.
35. Re:It's nearly caught up to PostgreSQL. by Splab · 2008-04-13 10:15 · Score: 1
  
  PG is a nice database, but it does not provide instant failover, and thus does not provide what I need.
36. Re:It's nearly caught up to PostgreSQL. by consumer · 2008-04-13 13:27 · Score: 1
  
  Transactions for your full-text search? That's not something most people have or want. Typical usage of full-text search engines is to refresh the index periodically, often once-a-day or less.
  
  With MySQL, you'd probably keep all of your normalized data in InnoDB tables and keep separate full-text search data up-to-date with triggers or a cron job. I wouldn't call it ideal, but it seems a lot less important than other things I'd like to see changed (e.g. better performance for subqueries).
37. Re:It's nearly caught up to PostgreSQL. by Just+Some+Guy · 2008-04-13 13:49 · Score: 1
  
  Turn on the strict mode.
  That's exactly backward. Those constraints should be on by default and only disabled by the admin running it with --enable-toy-db. It's kind of amazing that a popular database in 2008 still defaults to dangerous behavior.
  
  --
  Dewey, what part of this looks like authorities should be involved?
38. Re:It's nearly caught up to PostgreSQL. by consumer · 2008-04-13 14:38 · Score: 1
  
  Yeah, because the defaults on every other piece of software are PERFECT. MySQL tries hard to maintain compatibility with older versions. It's not that outrageous to ask people to specify that they don't need backwards compatibility by turning on the strict mode.
39. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-13 14:51 · Score: 0
  
  Uh, I for one would like transactional writes to the table that is indexed with a full-text search. Without needing a separate table.
  
  Speaking of separate tables, yeah, subqueries in MySQL need work too. They still use a temporary table for them instead of getting rewritten into a join. This is serious facepalm stuff here.
40. Re:It's nearly caught up to PostgreSQL. by jd · 2008-04-13 16:14 · Score: 1
  
  Not that I expect anyone to look this far back, but... Ingres is GPLed (and therefore Open Source). Why does that mater? Because it's a very solid system, provides lots of robustness, and is often forgotten as one of the major open source databases. PostgreSQL is great and for many real-world problems, it's perfect. MySQL - not sure where that fits in anymore, but it used to be that you'd want that to handle those components of a problem that needed a speed demon.
  However, I would say that it depends on what you want to do. Scientific data is typically kept using NetCDF or HDF5 because records can be multi-gigabyte and types can be highly complex. I know of no RDBMS that could handle the import of maximum-sized records from these files. Because of that, you cannot use an RDBMS except as a glorified index into such files. In other cases, the difference between the major RDBMS systems may be so small that there is no measurable difference. These are extreme cases, sure, but anything can do well in a non-extreme case. The optimum conditions tell you little other than how to give the system an easy time.
  
  --
  It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
41. Re:It's nearly caught up to PostgreSQL. by TheSunborn · 2008-04-13 16:15 · Score: 1
  
  An example for why i would want that:
  
  Imagine that slashdot uses InnoDB for all its tables(It don't but just imagene it does) and that slashdot
  want to add a feature where you can search other users Journals. To do this effective would require a full text index, but
  that conflict with the need for transactions and foregin keys. There are solutions to this. You can either use MyIsam on the table containing the journals, add a third party full text engine or analyze the situation, and find out that the search will not be used much, and all the data fits in ram, so just do a brute force search :}
42. Re:It's nearly caught up to PostgreSQL. by Evets · 2008-04-13 19:11 · Score: 1
  
  Many of us have run into limitations - both with Postgres and with MySQL. You can pit one against the other and come up with reasons to use (and not to use) each of them, but the important thing to take from an announcement like this is that open source databases are improving.
  
  By and large, the database application implementations I've seen over the last decade use the underlying data management software as a storage facility - neither taking advantage of platform specific performance tuning possibilities, nor taking advantage of platform specific data integrity features. Most applications are quite simple in their database usage.
  
  One thing I have consistently noticed over the last decade is that sales staff from the major (not free) vendors are considerably under-trained as to what exactly their licensing requirements actually are. That means that major projects end up with unforeseen budget shortfalls, they end up over-spending on licensing, and inevitably the time and energy of many very expensive employees and contractors get wasted discussing licensing issues that should be answered clearly by the vendor at first contact, with very little trouble.
  
  As MySQL grows, and as Postgres grows, we see alternative possibilities to the commercial offerings - alternatives with very clear cost parameters. 1 in 50 projects I've seen really needs a commercial database platform from a performance perspective or from a feature dependency perspective. I'd say 40 out of 50 I've seen require a commercial platform because the software vendor does not support OSS. That's a pretty big gap, but as we see improvements like these I suspect long term we'll see more enterprises standardizing on open source and we'll see more application vendors supporting OSS.
  
  Frankly, I don't see why more vendors don't support an underlying platform that is free. Why create a product that has an underlying cost that is both unavoidable and from which your company will see no profit?
43. Re:It's nearly caught up to PostgreSQL. by daveewart · 2008-04-14 03:53 · Score: 1
  
  Yeah, because the defaults on every other piece of software are PERFECT. MySQL tries hard to maintain compatibility with older versions. It's not that outrageous to ask people to specify that they don't need backwards compatibility by turning on the strict mode.
  
  Yes, and equally it's not that hard for people who want backwards-compatability to specify "--use-unsafe-behaviour" is it? Surely it should default to "safe".
  
  --
  "If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
44. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-15 08:50 · Score: 0
  
  Uh, "Preview" is your friend.
45. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-15 19:21 · Score: 0
  
  With MySQL, I have seen tables get badly corrupted, sometimes even beyond repair(!) if a disk runs full. That's simply unacceptable.
  
  If you're working in an environment where the administrators let disks run full, you have bigger problems than choosing the right database.
46. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-16 03:53 · Score: 0
  
  Yes, and equally it's not that hard for people who want backwards-compatability to specify "--use-unsafe-behaviour" is it? Surely it should default to "safe". Couldn't agree more.
  
  First: Make the thing correct and stable.
  Then: Make it fast(er) if possible.
  Then (and only then): Everything else.
  
  Why some people apparently still think that incorrect, unstable, even silently failing behavior, is in any way acceptable as the default mode in a database system is both fascinating and frightening. Mostly the latter.
  
  When MySQL by default is an anal, introspective, control-freak-alike pain in the butt when it comes to data integrity, then, and only then, will I ever reconsider my current verdict of "not production worthy for storage of sensitive data".
  
  A more honest and less sleazy marketing and documentation department of the company (or whichever company it may be that has control of it at any given day) wouldn't hurt either. Data-integrity is either important to them, or it is not. It doesn't change over time, just as a certain feature happens to become reality. Yuck.
47. Re:It's nearly caught up to PostgreSQL. by Anonymous Coward · 2008-04-26 10:19 · Score: 0
  
  None of the circumstances described will be allowed if the strict sql mode is used.
  
  Of course, MySQL 6.0 will have complete feature parity and a more advanced thread processing architecture that decouples requests from database threads. MySQL 6.0 + Falcon will be the fastest database for web 2.0 applications by a long shot. PostgreSQL's ancient postmaster + individual process per connection simply wont be competitive on web applications.
Sounds... 'Enterprisey' by Anonymous Coward · 2008-04-12 03:45 · Score: 0, Funny

AKA: Here comes the suck!
What?!? by skrolle2 · 2008-04-12 03:45 · Score: 1

From TFA:
MySQL had said it would release 5.1 in the first quarter, which ended March 31, and some developers have been getting impatient for the new release. What?!? I've been running 5.1 on a production server for almost a year now.
Probably, we should have called it 6.0, because there's so much stuff in there and we've been working on it for a couple of years. What?!? The 6.0 alpha has been available for half a year, it's already in developement, OF COURSE you can't call 5.1 6.0 since both are in development. What the hell is this guy on?
1. Re:What?!? by Anonymous Coward · 2008-04-12 03:55 · Score: 0
  
  You've been running a MySQL 5.1 beta, not the final release. It's okay to do that for testing purposes, but it's unwise to run a production site with beta software. The risk of data loss is just too great.
2. Re:What?!? by larry+bagina · 2008-04-12 04:03 · Score: 0, Redundant
  
  It's also unwise to run a production site on MySQL :p
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
3. Re:What?!? by Anonymous Coward · 2008-04-12 04:09 · Score: 4, Informative
  
  I don't understand how you can say things like that when HUGE sites like Flickr are MySQL based...and Google uses MySQL code for their DB...
4. Re:What?!? by ortholattice · 2008-04-12 04:41 · Score: 1, Insightful
  
  I don't understand how you can say things like that when HUGE sites like Flickr are MySQL based...and Google uses MySQL code for their DB...
  Both of these applications involve non-critical data. Google doesn't care if two separate searches for the same thing, one immediately after the other, give different results (which is often the case, probably due to different servers not being sync'ed to each other, not saying it's a MySQL problem; the point is that the data is loosey-goosey and non-critical). And, you forgot /. itself, which uses MySQL. They definitely don't care about the precision of the data; heck, they still can't even get "page 1 of 2" and "page 2 of 2" not to have overlapping results after 10 years or whatever in business.
  I think your case would be better made if you showed a HUGE user of MySQL for financial applications. Does Google use MySQL to handle their general ledger and billing?
5. Re:What?!? by asaivan · 2008-04-12 04:44 · Score: 1
  
  It's just different DBs for different purposes. (I'm the poster of the comment you replied to, I hit AC on accident).
6. Re:What?!? by theantix · 2008-04-12 08:00 · Score: 1
  
  Do some research before you talk about things you dont understand. For starters, Google uses MySQL for their ads, not searches. Searches are done via Bigtable, which is actuall pretty cool. However I find it extremely unlikely that Google would trust their ad system to something they felt was "loosey-goosey".
  
  Regardless there are plenty of large scale institutions which use MySQL cluster for financial and other critical applications. MySQL Cluster is extremely robust, and thanks to rolling upgrades and built in redundancy it is a very safe and reliable system.
  
  --
  501 Not Implemented
Disk Clustering by TheLinuxSRC · 2008-04-12 03:48 · Score: 2, Interesting

I am really looking forward to disk based clustering in MySQL. I have tried the NDB clustering, but the hardware requirements can be hefty. I am also curious about performance in this area. Contrary to what one might assume, the in-memory clustering is generally slower than storing the files on disk. I am curious how the disk based clustering fares compared to NDB clustering and a traditional on-disk MySQL DB.
1. Re:Disk Clustering by dysk · 2008-04-12 04:26 · Score: 1
  
  Contrary to what one might assume, the in-memory clustering is generally slower than storing the files on disk. . Are you sure this holds up for mysql's shared nothing architecture? Most other DBMSes use a shared block device (a SAN) for clustered databases, which is a whole other perforamnce profile.
2. Re:Disk Clustering by aauu · 2008-04-12 05:53 · Score: 1
  
  Read carefully, NDB supports placing some types of data columns on disk. Blobs are not tables.
  
  When you talk clustering there are two architectures:
  
  A single active instance that can migrate between nodes: This is red hat, drbd, windows, veritas clustering. This is a high availability option where an instance will migrate to a new node by dismounting disk resources, moving ip addresses and starting the instance on a new node. This can be in response to a node failure detected by cluster heartbeat/monitor or for administrative purposes such as software/hardware maintenance. This architecture is also supported by SQL Server and Oracle. This architecture can be implemented for many types of services such as email.
  
  Multiple active instances that cooperatively share a single set of physical database files: This is Oracle RAC and MySQL NDB (the database has to be able to persist to files for shutdown/startup) with memory files. The disk enhancement for NDB allows blobs to be disk based. The databases tables/indexes still need to be memory resident.
  
  Note that in both clustering architectures damage to the database files is still a significant vulnerability. SANs represent the best host for cluster files. DRBD can recover from disk failure, although you should already be raid 10 or 20 for you database files.
  
  Clustering is a high availability mechanism and not a disaster recovery methodology. Backups or other file recovery mechanisms are required.
  
  --
  When I was young, I had to rub sticks together to compute.
3. Re:Disk Clustering by theantix · 2008-04-12 08:10 · Score: 2, Informative
  
  With NDB Cluster 5.1, all of the indexed columns are still in memory, so the performance impact is minimal for the types of queries and DML that NDB is good for. At least, in my testing it has been.
  
  For things NDB cluster is really bad at, like querying against non-indexed tables... even the memory based NDB is terrible compared with the innodb/myisam. So you wouldn't be doing that anyway, but the indexed columns would be relatively unaffected by the change.
  
  --
  501 Not Implemented
4. Re:Disk Clustering by Mad+Merlin · 2008-04-12 11:59 · Score: 1
  
  ...although you should already be raid 10 or 20 for you database files.
  
  RAID 20? I don't think that exists. Perhaps you meant RAID 50 or RAID 60...
  
  --
  Game! - Where the stick is mightier than the sword!
5. Re:Disk Clustering by redwoodtree · 2008-04-12 13:38 · Score: 1
  
  From my tests and working with MySQL professional services, once disk based clustering is turned on, performance tanks across the board, even on the memory portion.
  
  This technology has a long, long way to go. There are very few real world applications for NDB cluster right now.
6. Re:Disk Clustering by aauu · 2008-04-12 14:22 · Score: 1
  
  Raid 10 is striped mirrors. Raid 20 is striped triplets.
  
  --
  When I was young, I had to rub sticks together to compute.
License status. by DAldredge · 2008-04-12 03:53 · Score: 2, Interesting

Do they still insist that simply connecting to the server process requires a commercial license if you aren't GPL?
1. Re:License status. by Doug+Neal · 2008-04-12 04:22 · Score: 2, Informative
  
  The client library is GPL. There's nothing to stop anyone writing their own client library under another license, but nobody's done that yet (as far as I know).
2. Re:License status. by Fweeky · 2008-04-12 05:21 · Score: 4, Informative
  
  php-mysqlnd is a replacement for libmysql, under the PHP license.
3. Re:License status. by DAldredge · 2008-04-12 05:35 · Score: 3, Informative
  
  http://www.mysql.com/about/legal/licensing/commercial-license.html The Commercial License is an agreement with MySQL AB for organizations that do not want to release their application source code. Commercially licensed customers get a commercially supported product with assurances from MySQL. Commercially licensed users are also free from the requirement of making their own application open source. When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to or you may distribute MySQL software, you must first obtain a commercial license to the MySQL product. Typical examples of MySQL distribution include: * Selling software that includes MySQL to customers who install the software on their own machines. * Selling software that requires customers to install MySQL themselves on their own machines. * Building a hardware system that includes MySQL and selling that hardware system to customers for installation at their own locations. Specifically: * If you include the MySQL server with an application that is not licensed under the GPL or GPL-compatible license, you need a commercial license for the MySQL server. * If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries. * If you include one or more of the MySQL drivers in your non-GPL application (so that your application can run with MySQL), you need a commercial license for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library. * GPL users have no direct legal relationship with MySQL AB. The commercial license, on the other hand, is MySQL AB's private license, and provides a direct legal relationship with MySQL AB. With a commercial non-GPL MySQL server license, one license is required per database server (single installed MySQL binary). There are no restrictions on the number of connections, number of CPUs, memory or disks to that one MySQL database server. The MaxDB server is licensed per CPU or named user.
When shall we get a decent front end? by bogaboga · 2008-04-12 03:57 · Score: 3, Interesting

I am wondering when we shall ever have a free as is OSS, fully programmable front end to MySQL. All the free front ends available suck big time and the non free ones, though somewhat functional, are not available without some kind of restrictions.
In my opinion, the day MySQL will have a fully programmable front end...I mean one that a programmer can add business logic to, program input masks, direct functionality at widget or control level and use to generate customized reports depending on various metrics, MySQL will kick ass. Right now, all front ends to MYSQL suck big time and there does not appear to be an end in sight - sadly.
SQL Maestro is very promising but it's not free!
1. Re:When shall we get a decent front end? by larry+bagina · 2008-04-12 04:07 · Score: 1
  
  When will you start developing it? OSS exists because someone has an itch that needs scratching.
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
2. Re:When shall we get a decent front end? by Animats · 2008-04-12 04:22 · Score: 2, Interesting
  
  SQL Maestro is an administrative tool, not a report generator.
  PHP Generator for MySQL is free and useful for generating simple database-driven web sites.
  Admittedly, the MySQL Query Browser is clunky, but at least it finally works. For several releases, it was badly broken.
3. Re:When shall we get a decent front end? by Anonymous Coward · 2008-04-12 04:28 · Score: 0
  
  I've never used it but you can try out OOO Base which is a copy of MS access. I'm guessing that is the solution you are looking for. I'm wondering, thought, how many people still use MS access? I mean you can make a simple web-based app and people can access it from anywhere. Why bother with a full blown app?
4. Re:When shall we get a decent front end? by dysk · 2008-04-12 04:29 · Score: 1
  
  Sadly, management tools and report generation are hard, and they require a level of coordination that's easier to achieve in one company and much harder in an open source environment.
  A brilliant programmer can come up with some really solid and innovative code (ex. reiserfs), but to make a nontrivial management tool you need a combination of programmers, designers, and yes, managers, working in tight concert.
  I personally am okay with paying for front ends when they're needed, so we can get kickass scalable solid database backends for free.
5. Re:When shall we get a decent front end? by OeLeWaPpErKe · 2008-04-12 04:30 · Score: 0, Troll
  
  When I get paid for it. I want about 3000$/month. The state here wants another 3000.
  
  When do I start ?
6. Re:When shall we get a decent front end? by barzok · 2008-04-12 04:31 · Score: 1
  
  OO.o Base is far from a "copy of MS Access." I tried to use it once and couldn't figure out how to put together a simple form for adding records to a table.
7. Re:When shall we get a decent front end? by NevarMore · 2008-04-12 04:33 · Score: 5, Insightful
  
  Fully programmable front-end for a database?
  
  You mean like C, C++, Java, Ruby, PHP, Python, OO Calc, ASP, C# ??
8. Re:When shall we get a decent front end? by Anonymous Coward · 2008-04-12 04:54 · Score: 0
  
  Programmable front end? How about, say, Java DB, which I would add, is fully programmable. It is, after all, a programming language. Then, there are also the interfaces, for say, Python, which again,are fully programmable, and you can add business logic... So, what exactly are you looking for?
9. Re:When shall we get a decent front end? by isilrion · 2008-04-12 04:59 · Score: 1
  
  When do I start ? How could we know? You are the one who wants the feature, and the money... That's your problem, not ours.
10. Re:When shall we get a decent front end? by Kirkoff · 2008-04-12 05:11 · Score: 1
  
  I messed around with it a few times. They made some good strides in 2.3. I have yet to try anything with the 2.4 release but it is slowly getting there. It's not a copy of MS Access though - it is all built around a page model which is very odd when creating forms.
  
  --
  There are exactly 42,935,718 letter sized sheets in a square mile.
11. Re:When shall we get a decent front end? by shmlco · 2008-04-12 05:55 · Score: 1
  
  "... the non free ones, though somewhat functional, are not available without some kind of restrictions."
  
  Yeah, like they expect you to pay for them.
  
  --
  Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
12. Re:When shall we get a decent front end? by Richard_at_work · 2008-04-12 06:47 · Score: 1
  
  Dunno if its what you are after, but have you tried HeidiSQL?
13. Re:When shall we get a decent front end? by Danny+Rathjens · 2008-04-12 06:47 · Score: 1
  
  I'm confused at his request, also. Perl is my mysql front-end and I can do absolutely anything with it. Maybe he is asking for the old MS Access style graphical "form" interface for inputting data and generating reports or perhaps he is talking about a GUI administrative interface like phpmyadmin.
14. Re:When shall we get a decent front end? by Blackknight · 2008-04-12 06:52 · Score: 1
  
  Not everybody that uses OSS software is a developer. I'm a system admin and I've done my fair share of shell scripting, PHP and Python but I still can't write every application that I need from scratch. If MySQL had something like Enterprise Studio it would be really nice, phpMyAdmin is ok but it's missing some things.
15. Re:When shall we get a decent front end? by Shados · 2008-04-12 06:55 · Score: 2, Informative
  
  He's talking about a 4th gen RAD front end, so yeah, like MS Access, eDeveloper, Oracle Developer (is that still how its called?), etc. There are a few up and coming one in the open source world, but none really that are feature complete.
16. Re:When shall we get a decent front end? by bXTr · 2008-04-12 07:22 · Score: 1
  
  Not everybody that uses OSS software is a developer.
  Not everyone who uses OSS software has to be a developer to contribute. There are developers out there who wouldn't mind being paid to make an Enterprise Studio-y front end for MySQL for you. Hell, anything is possible; it's only a question of time and money.
  
  --
  It's a very dark ride.
17. Re:When shall we get a decent front end? by dookiesan · 2008-04-12 07:31 · Score: 1
  
  I'm thinking that he wanted something you could click your mouse on, but still customize. You should be able to do a lot of things with the database using your mouse alone. A first step would be graphical tools for extracting and displaying the data; maybe then you can move on to modifying it.
18. Re:When shall we get a decent front end? by Wiseman1024 · 2008-04-12 07:37 · Score: 1
  
  You mean Access? You could try Rekall, Kexi and OpenOffice Base, for example. I think they all work with Python, which is a huge advantage over Access.
  
  --
  I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
19. Re:When shall we get a decent front end? by Planesdragon · 2008-04-12 07:58 · Score: 1
  
  I'm wondering, thought, how many people still use MS access? I mean you can make a simple web-based app and people can access it from anywhere. Why bother with a full blown app? MS Access is the archtypical "toy" database -- useful for very-small projects that don't need to go beyond one computer, or that would otherwise be done by hand using some badly written spreadsheets.
  
  I've used Access to parse some very large data sets, and I've seen it used as the primary database for limited-run data-sets. Sure, most of these COULD be done via a single server hosting it somewhere... but that's unneeded complexity for the lower end of tasks.
20. Re:When shall we get a decent front end? by Planesdragon · 2008-04-12 08:00 · Score: 1
  
  Maybe he is asking for the old MS Access style graphical "form" interface for inputting data and generating reports or perhaps he is talking about a GUI administrative interface like phpmyadmin. Yes, both of those qualify as a "front-end."
  
  phpmyadmin fails as it's an unnecessary layer of abstraction -- I shouldn't have to run a webserver on my db engine, or local machine, just to admin my database outside a command shell.
21. Re:When shall we get a decent front end? by Anonymous Coward · 2008-04-12 09:55 · Score: 0
  
  I think he was referring to blist.com
22. Re:When shall we get a decent front end? by lakeland · 2008-04-12 10:36 · Score: 1
  
  I think he means like SQL Server Reporting Services, MS Access and SQL Server Analytic services.
  
  Hard to be sure though.
  
  The tools like Mondrian, JasperSoft, Petaho, Navicat, etc. They're all okay, but nothing like as polished as Microsoft's.
23. Re:When shall we get a decent front end? by Shados · 2008-04-12 11:11 · Score: 1
  
  You know that Access isn't a database, yes? And that its quite often used on "real" databases? And that if you start with the "toy" database, it can easily later be upgraded to a "real" one? Which is a fairly large part of its usefulness.
24. Re:When shall we get a decent front end? by ianare · 2008-04-12 11:31 · Score: 4, Funny
  
  Toy database for small, unimportant projects? I don't think so. Access is one of the most stable, reliable, and secure DB systems out there, as the following shows so well:
  Among revelations contained in the memos was information that the Microsoft Access database used by the Diebold system to collect and calculate votes was not protected by a password. source
25. Re:When shall we get a decent front end? by carlzum · 2008-04-12 12:43 · Score: 0
  
  I work with Oracle, MySQL, and SQL Server 2005 and find the front-end tools pretty much equivalent. I develop with Toad (third party) for Oracle and MySQL and Management Studio for SQL Server. They highlight code, debug, and make ordinary database commands easier to execute, but they're far from the complete development environment you're describing. I think "front-ends that suck" is common to all database vendors. My business logic and reports live in Java/.NET and other tools like Reporting Server and Jasper. IMO, the tools available for MySQL are not any better or worse than commercial software.
26. Re:When shall we get a decent front end? by bogaboga · 2008-04-12 15:20 · Score: 1
  
  MS Access is the archtypical "toy" database -- useful for very-small projects that don't need to go beyond one computer, or that would otherwise be done by hand using some badly written spreadsheets.
  I suggest you get your facts right before posting, otherwise you make us grade you in a certain way. Access is NOT a database. It IS a front end to Microsoft's Jet Database engine.
  Having said that, Access itself is fully programmable using Visual Basic. Virtually, all components of what you see on the screen and what they do or how they respond after specific events can be programmed. There is nothing in the OSS world that comes close to this.
  I am still looking for a way to make OpenOffice.org's database front end enforce input masks for Canadian postal codes which are in the following format: [A-Z][1-9][A-Z][1-9][A-Z][1-9].This effort is proving almost impossible. Catching an error at form level is better and faster than waiting for the DB to flag it and return an error.
27. Re:When shall we get a decent front end? by PinkPanther · 2008-04-13 13:23 · Score: 1
  
  Catching an error at form level is better and faster than waiting for the DB to flag it and return an error. Only if all interaction is going through that form. If you wan to have multiple applications deal with the database, then putting check constraints such as this in the user interface is not proper application design...wrong layer.
  
  --
  It's a simple matter of complex programming.
28. Re:When shall we get a decent front end? by bogaboga · 2008-04-13 15:28 · Score: 1
  
  That's common sense in the sense, isn't it?
  That said, it all depends on the situation. I ran a DB that uses forms that catch errors at that level. Other applications interact with the DB solely to read data.
  It is better for these applications to get maximum attention from the DB engine, instead of having the engine catching errors being generated by other users.
  In this situation, when upgrades are made to the interface, each user's interface is auto-magically upgraded at the next log-in.
29. Re:When shall we get a decent front end? by Anonymous Coward · 2008-04-14 03:30 · Score: 0
  
  Dunno if its what you are after, but have you tried HeidiSQL? I can second this. I don't even run Windows anymore but I'm a fan of HeidiSQL (formerly mysqlFront, for those who don't know.) I only wish there was a native Linux port.
Get PostgreSQL! No, shut up! YOU shut up! by g_adams27 · 2008-04-12 04:03 · Score: 5, Funny

I would simply like to point out that this MySQL update is completely irrelevant because PostgreSQL has had (g_adams27, fill this part in before submitting) for a very long time, and MySQL is simply playing catchup.

...

And now I would like to strongly disagree with g_adams27, who obviously doesn't realize that MySQL is an excellent choice even compared with PostgreSQL, and I wish he'd stop making silly comparisons.

...

In response to that, I say: g_adams27, SHUT UP! You obviously don't recognize the fatal flaws that MySQL still has, in that it still can't (fill this part out later) even after years of development. PostgreSQL is obviously the superior option, and you can take your stupid MySQL advocacy somewhere else.

...

Oh, yeah? Well maybe YOU should shut up! I can't say I'm shocked at g_adams27' mean-spirited response, because that's typical of PostgreSQL jerks. MySQL is AWESOME, and YOU need to shut up, jerk!

...

Well, g_adams27, maybe you should take your TOY MySQL and go play with your dollies, while us REAL sysadmins use a REAL RDBMS to do REAL work! Idiot.

...

And now, allow me, g_adams27, to step in to the middle of this debate and simply point out that you're BOTH right, and that MySQL and PostgreSQL are perfectly good choices.

Just doing my part to shorten this thread.
Re:Get PostgreSQL! No, shut up! YOU shut up! by UnknowingFool · 2008-04-12 04:07 · Score: 1, Offtopic

On that same note, I would like to say the emacs is way better than vi. That's right. You heard me. Bring it! :P

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
woo! by elmaxxgt · 2008-04-12 04:08 · Score: 0, Offtopic

yes! what a great month, with kubuntu 8.04's release also soon... oh man, new toys! :D

--
Tokyo Robot Lords! Smile! Taste Kittens!
1. Re:woo! by cbart387 · 2008-04-12 04:15 · Score: 0, Offtopic
  
  Fedora 9 is this month as well. I very looking forward to the faster X startup/shutdown. :) Full list is here.
  
  --
  Lack of planning on your part does not constitute an emergency on mine.
2. Re:woo! by elmaxxgt · 2008-04-12 04:22 · Score: 0
  
  oh wow, thanks for the link, i will have to play with this too D: you insensitive clod! :)
  
  --
  Tokyo Robot Lords! Smile! Taste Kittens!
And I just managed to get the 5.0.51a compiled... by Anonymous Coward · 2008-04-12 04:13 · Score: 0

Was painful to port the VC project files from the 5.0.45 release to compile the 5.0.51a. The funny think is that it adds some additional binaries which are not available through the makefiles at all.
Re:Get PostgreSQL! No, shut up! YOU shut up! by Evanisincontrol · 2008-04-12 04:22 · Score: 0, Offtopic

On that same note, I would like to say the emacs is way better than vi. That's right. You heard me. Bring it! :P
Dammit, Emacs
Re:Get PostgreSQL! No, shut up! YOU shut up! by MrNaz · 2008-04-12 04:46 · Score: 0

If you don't stop using MySQL I'm going to tell the teacher! Also you're a poopy head locks no returnies!

--
I hate printers.
Re:Get PostgreSQL! No, shut up! YOU shut up! by Anonymous Coward · 2008-04-12 04:57 · Score: 1, Funny

By golly. Over a hour after this story popped up and there were only 37 comments posted. You perform magic with your words of wisdom, g_adams27!
This article reminds me why I'm still in school by Anonymous Coward · 2008-04-12 05:23 · Score: 0

Events scheduling? Row-based replication? Disk-based clustering? Back to the textbooks...
1. Re:This article reminds me why I'm still in school by Anonymous Coward · 2008-04-12 06:21 · Score: 0
  
  That's one of the reasons I left the PC industry. I just couldn't take it anymore, Office Space style.
  
  Computers burned me out over the timespan of only ~10 years.
2. Re:This article reminds me why I'm still in school by Anonymous Coward · 2008-04-12 06:24 · Score: 0
  
  meh. School is all philosophy. The only way to learn is in the real world.
Re:Get PostgreSQL! No, shut up! YOU shut up! by Godji · 2008-04-12 05:24 · Score: 1

Not to start a flamewar, but how many of the aforementioned features does PostgreSQL already have (available or planned)?

Note that I am not asking which DBMS is better for any definition of "better".
Comment removed by account_deleted · 2008-04-12 05:41 · Score: 1

Comment removed based on user account deletion
I'm Already Gone by segedunum · 2008-04-12 06:50 · Score: 4, Insightful

We've already started a migration from MySQL to Postgres, and we're not going back. Full Text Searching was one of the features, but Postgres all round just has a lot more to it. You can make the thing look like an Oracle database if necessary, there's auto vacuuming now, asynchronous commits and a ton of other performance improvements that don't skimp on features.

I really can't see why anyone would choose MySQL now, apart from inertia and backwards compatibility.
1. Re:I'm Already Gone by Anonymous Coward · 2008-04-12 11:30 · Score: 0
  
  I've setup some large document management systems using Owl with a Postgre db backend, and the performance difference with MySQL is clearly noticeable. The only issue i had with Postgre is that it's a tad more difficult to admin, but this is mostly because i'm used to the MySQL way, which is more accesible.
  
  I'm not going back any time soon either.
2. Re:I'm Already Gone by ShieldW0lf · 2008-04-12 11:31 · Score: 1
  
  MySQL has lax enforcement of constraints. Which is a big black eye, and makes it totally unsuitable for a number of important tasks for which people are willing to pay good money.
  
  However, when you've already made the choice that you're going to compromise on your constraints and referential integrity, it makes multi-master clustering a lot easier.
  
  This is the niche in which MySQL fits.
  
  That said, I don't like it, and use Postgres for my own projects.
  
  --
  -1 Uncomfortable Truth
3. Re:I'm Already Gone by gumbi+west · 2008-04-13 03:56 · Score: 1
  
  Does Postgres have good mirroring? I use MySQL's cluster ability on my desktop and laptop so that I'm not constantly shutting down both and rsyncing, but have my data with me everywhere. Yes, this is way outside a production environment, but it is where I am.
Stop the damned comma-frenzy headlines already by Anonymous Coward · 2008-04-12 07:01 · Score: 0

Here's what the f'ing "let's use commas for all of it despite that it's grammatically wrong - 'coz everyone else does so" headline expands to:

MySQL 5.1 improves performance, partitioning and bug fixes.

Total brainpower.
Decipher for non DB types by tji · 2008-04-12 07:04 · Score: 2, Insightful

I do use databases for various apps and projects, but only enough to do what I need. I am by no means a DB expert.

So, can someone more DB-literate explain some of the new features?

- Disk based clustering: I assume this means I can dynamically expand the size of my database by adding more disks. Is this correct? Does PostgreSQL also support this (my project where this would be handy currently uses pgsql)?

- Partitioning: I can think of several things this could mean.. Splitting data among several tables at some logical dividing point. Or, limiting the size of tables so they can't overrun the complete storage space. What does this mean in MySQL 5.1 terms?
1. Re:Decipher for non DB types by theantix · 2008-04-12 08:18 · Score: 5, Informative
  
  - Disk based clustering: I assume this means I can dynamically expand the size of my database by adding more disks. Is this correct? Does PostgreSQL also support this (my project where this would be handy currently uses pgsql)? Disk based clustering only applies to people using the MySQL NDB Cluster product, which is quite different from the traditional MySQL product. So for the vast majority of MySQL users who use MyISAM or InnoDB tables, this doesn't really affect them at all.
  - Partitioning: I can think of several things this could mean.. Splitting data among several tables at some logical dividing point. Or, limiting the size of tables so they can't overrun the complete storage space. What does this mean in MySQL 5.1 terms? This means splitting an existing table along logical dividing points, but still acting as a single table. Let's say you partition it by date, well then you would insert/select/update like normal -- but a query or update that looks at the date would only have to look at a smaller partition of the table to know what row needs to be updated.
  
  --
  501 Not Implemented
2. Re:Decipher for non DB types by merryberry · 2008-04-12 11:13 · Score: 1
  
  And to add, partitioning in mysql 5.1 is probably not going to be production ready.
Re:Get PostgreSQL! No, shut up! YOU shut up! by iluvcapra · 2008-04-12 07:08 · Score: 1

I must say, I've been sitting at this PostgreSQL machine at this contract web design gig, and I don't know what all of you Postgres people are talking about! I started this 100 row SELECT statement 20 minutes ago, and it STILL hasn't finished. MySQL has it's problems, but seriously, guys!

Always look over your head for joke before replying. I wish I could find a link to the original post.

--
Don't blame me, I voted for Baltar.
Not this crap again... by Wiseman1024 · 2008-04-12 07:34 · Score: 2, Insightful

When will people realize the licensing issues are *solved* now?

Surely, I can see clueless people 100 years from now still bitching about MySQL's licensing terms.

--
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
1. Re:Not this crap again... by Just+Some+Guy · 2008-04-12 10:06 · Score: 1
  
  When will people realize the licensing issues are *solved* now?
  They are? So you can write non-GPL software with a MySQL backend now? Great!
  
  --
  Dewey, what part of this looks like authorities should be involved?
2. Re:Not this crap again... by kylehase · 2008-04-12 16:27 · Score: 2, Informative
  
  Sure you can, just don't distribute the software. Every commercial case listed in the license above describes distributing MySQL in whole or part.
  
  I'm no lawyer but it seems if you develop a non-GPL commercial service that runs a community-licensed MySQL backend it's perfectly fine to charge for your service.
  
  --
  You want fun, go home and buy a monkey!
3. Re:Not this crap again... by Just+Some+Guy · 2008-04-12 17:29 · Score: 1
  
  Sure you can, just don't distribute the software. Every commercial case listed in the license above describes distributing MySQL in whole or part.
  ...including the client libraries. This makes MySQL the only major database restricting commercial developers. I've actually looked up the licensing for DB2, Oracle, and SQL Server, and each of them allows linking and distribution of their connectors. PostgreSQL, being BSD licensed, and SQLite, being public domain, of course allow that as well.
  
  --
  Dewey, what part of this looks like authorities should be involved?
4. Re:Not this crap again... by Wiseman1024 · 2008-04-13 00:08 · Score: 1
  
  Again, no! What should MySQL do in order for you to stop thinking that? Turn mysql.com into a porn site for April 1st?
  
  Read this at once:
  http://www.mysql.com/about/legal/licensing/foss-exception.html
  
  --
  I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
5. Re:Not this crap again... by Just+Some+Guy · 2008-04-13 01:13 · Score: 1
  
  Again, no! What should MySQL do in order for you to stop thinking that?
  Change their policy. That page you linked to had nothing but an exception for non-GPL Free Software projects to use MySQL. That's completely and utterly uninteresting for commercial or non-Free software.
  
  --
  Dewey, what part of this looks like authorities should be involved?
Did they fix perf by melted · 2008-04-12 09:39 · Score: 1

Did they fix perf in subselects and multi-way joins? No? Didn't think so.
1. Re:Did they fix perf by diegomontoya · 2008-04-12 09:59 · Score: 1
  
  Subqueries in Mysql is as useful in the real-world deployments as paper and pencil. Actually, at least with p&p, I can doodle some fancy comics.
  
  Subselects is so limited in the indexes it can use the performance as melted has pointed out is bad. To me, it's not bad, it's unusable in just-in-time page generation. Usable for cron jobs and data warehousing but forget about it if you want it "fast".
about **** time! by diegomontoya · 2008-04-12 09:51 · Score: 2, Informative

As a heavy user of Mysql since 4 series, 5.X has been the buggiest, slowest, with the most god-awful slow release schedule of them all. 4.1 alpha was higher quality in terms of bugs/stability than all the stable "5.0" releases and 5.1 just takes forever to get even beta revisions out the door. Mysql is getting slower and slower at getting releases out the door. Expect Mysql 6.0 in 2011 if not later.

I'm a paid mysql enterprise subscriber and I'm pissed at their pace.

It's one thing to have a slow stable release but for crying out loud, shorten your "beta/rc" releases please? The amount of bugs fixed between each release is staggering which is why the bleeding edge adopters need faster releases!
Excellent! *rubs hands together* by Nail · 2008-04-12 13:11 · Score: 1

The whole Slashdot article commenting process distilled into a single comment. With this, my "Library in a Book", and my "Election in an Argument", I will Take Over The World! MUAHAHaHahaha! Somehow...

--
...yellow number five, yellow number five, yellow number five...
Gentlemen, please! by mstahl · 2008-04-12 16:11 · Score: 1

Let's not start another religious war on slashdot!
Re:Get PostgreSQL! No, shut up! YOU shut up! by jasonwea · 2008-04-12 20:28 · Score: 1

http://www.kottke.org/98/11/my-mac-sucks would be the link you're after.

I found it somewhat amusing that I'm reading this thread as I'm working on a project that uses Postgres on Mac. I came here to post the same joke but you beat me by a long shot.

todo: insert joke about my Mac taking over 20 minutes to post a comment
Half-baked tea by 200_success · 2008-04-13 00:14 · Score: 1

Actually, all tea needs to be baked or roasted. http://en.wikipedia.org/wiki/Tea#Processing_and_classification
1. Re:Half-baked tea by Anonymous Coward · 2008-04-13 14:42 · Score: 0
  
  Yeah, but you don't bake your cup of tea.
  
  And some green teas are in fact half-baked.
Very little experts in here :-) by nicc777 · 2008-04-13 00:32 · Score: 1

I am amazed by some of the comments in this thread... It is obvious that there are only a small number of people that really understand databases.
In our org. we use both databases. Both have pro's and cons. The trick is to know the limitations of each, and based on that choose the best DB for a specific task. Some times you will go with MySQL, other times with PostgreSQL.
Personally I am probably a little biased toward MySQL - because I know it very well. A lot of the comments (negative wise) on MySQL in this thread simply is not true - or the user just had some very bad luck. We run several instances that run over 500 queries per second, and apart from scheduled maintenance, I only had a handful of DB crashes over the last couple of years - none of which was caused by the DB, and all crashes could be rectified with the standard MySQL tools.
Our busiest server is a IBM x-series, 4GB RAM with about 2TB disk on the SAN. We run 22 instances of MySQL on this one system. The load average on this box is always over 12 (during month ends, going to about 22), but CPU is always manageable.
My biggest gripe's:

* Dev okes blaming the DB when their app doesn't perform (it's always a case of the DBA having to provide proof, and when he does, it's usually contested till the cows come home)

* Forums like this full of DBA wannabees.
Have fun

--
Need an ISP in South Africa?
Seen this before? by brettz9 · 2008-04-13 05:23 · Score: 2, Funny

"5.1, though it sounds like an incremental release, has got some pretty major features," said Zack Urlocker, vice president for MySQL products at Sun, in a video postedto InfoWorld's Web site this week. "Probably, we should have called it 6.0, because there's so much stuff in there and we've been working on it for a couple of years."
Hmm...Or maybe the marketers at Sun should give the name the grandeur it deserves and change it to MySQL 2 Standard Edition version 6...
Do NOT try to scale using the RDBMS... by Colin+Smith · 2008-04-13 09:57 · Score: 1

It's the wrong tool for the job. At the very best it's a kludge. There are excellent tools out there which are designed with no other purpose than getting data from here to there, there, there and there but RDBMS are not one of them.

--
Deleted
Funny time to make this announcement by Anonymous Coward · 2008-04-13 10:40 · Score: 0

Because for the second time in a month, I'm running a query in Postgres that poor MySQL was not even able to present an execution plan. Of course, to get the data into PG I had to chain something like 5 filters to clean bad dates, NOT NULL fields with no values, etc.
If you value anything at all your data, stay away from MySQL. I've 15 years Oracle experience in a large Data Warehouse environment. Understand this: for some people, it's better to have bad data than an error message. After 15 years, I prefer to have an error message and a rejected record.
Please the "anecdote from the uninformed, this is not valuable" flaming proceed, on a second tought I even prefer that everybody uses MySQL. That could means a profitable consulting business on how to migrate from it.
MySQL vs. Postgres; comparison by academia by singh.gurjeet · 2008-04-13 16:04 · Score: 1

I am posting this extract from the doc that introduces a new RDBMS course to Berkley and Carnegie Mellon (Sorry that i don't have a date when exactly it was published!): http://www.sigmod.org/record/issues/0309/4.JHdbcourseS03.pdf -- We considered both of the leading open source systems: MySQL and PostgreSQL. MySQL has the advantage of significant opportunities for student extension, since it actually comes with almost none of the features taught in a typical DB systems course â" it has no cost-based optimizer, no B+-trees, no fine-grained concurrency control, no recovery, no hash joins, etc.[1] By contrast, PostgreSQL already has most of the features usually taught in class. Of course, this it raises (surmountable) difficulties in inventing assignments where students can profitably extend the system with new features. -- And here's the footnote: [1]It should be noted that MySQL can be interfaced to better storage managers like BerkeleyDB and InnoDB for improved indexing, concurrency and recovery support. We felt that using more than one system was a poor option for educational purposes.
According to this, the performance is now worse. by Anonymous Coward · 2008-04-13 18:27 · Score: 0

Version 5.1 is slower than 5.0.
Skype is based on PostgreSQL. by egghat · 2008-04-13 20:54 · Score: 1

Idiots?

--
-- "As a human being I claim the right to be widely inconsistent", John Peel