MySQL Moves to Prime Time 261
MagLev writes "MySQL, especially version 5.0, is popping up on the radar screens of database gurus who built their reputations and book sales using other SQL databases. Ken North, who did those ODBC performance benchmarks for Oracle, Sybase, and DB2, wrote a recent article about MySQL 5.0. The article profiles mission critical database software and discusses how well MySQL 5.0 fits the profile. It gives good marks to MySQL, except for Java and XML integration."
So, uh (Score:4, Funny)
Slowly But Surely (Score:5, Interesting)
Re:Slowly But Surely (Score:2)
I suppose that's no surprise -- if you're the largest forum on the net it's no surprise you're bound to push the development of Perl and MySQL.
Re:Slowly But Surely (Score:2)
For example: http://fray.slate.msn.com/?id=3936 [msn.com] has more users and more posts than this forum.
Re:Slowly But Surely (Score:2)
propaganda (Score:4, Insightful)
> MySQL has a demonstrated capacity for managing very large databases. Mytrix,
> Inc. maintains an extensive collection of Internet statistics in a one
> terabyte (1 TB) data warehouse that contains 20 billion rows of data.
MySQL is a horrible product for warehousing: no query parallelism, no partitioning, primitive memory management, primitive optimizer, etc, etc. 20 Billion rows in a single table? What would mysql do with that? Any typical warehousing queries would take hours to come back. More likely either the database owners are just logging data someplace cheap, or they are creating hundreds of much smaller tables.
> It replicates 10-60 gigabytes per day from its master database to a MySQL server farm.
Ah, a 'server farm'. So, the 20 billion rows are probably spread across dozens of mysql servers. This explains it all. Even SQL Server can do better than that.
> The MySQL databases are used to support a shopping application that can accommodate a million fare changes per day.
Yeah, I think db2's most recent benchmark was for something like 3 million transactions a minute.
This is little more than an advertisement for mysql. A little poking around would probably show that he's on the mysql payroll.
Re:propaganda (Score:2, Insightful)
Anyway you're right. MySQL actually doesn't do very good if a table has a million entries. It may seem fast at first, but try to do a select on a table with a million entries, joined with itself three times, and do a group by command. It's gonna take a while to finish. Granted, it's minutes instead of the usual seconds, but I would tend to think that commercial databases would do better than that.
IMHO MySQL is fine as long as you
Re:propaganda (Score:5, Interesting)
PostgreSQL, Firebird, MaxDB and Ingres all handle the milions of rows *a lot* better.
Especially PostgreSQL seems to stay on par with Oracle, even offering (primitive) support for table partitioning, bitmap indexes etc.
If I would try to do data warehousing on an open source database, it's probably going to be PostgreSQL.
Re:propaganda (Score:3, Insightful)
I do exactly this on a database that is around 400 mb large (without the indexes). There are no "minutes", theres
Re:propaganda (Score:4, Insightful)
> correct answer. That's all I need and I don't think it's fair to directly
> compare MySQL to a $20,000 database. Of course it won't perform as good.
> It's like comparing a Toyota to a Ferrari and complaining that the Toyota
> won't go as fast.
Sure - if it only takes a few minutes every now and then that might not be a big deal.
But regarding the cost of the alternatives:
- postgresql is freer (no way of having to face $600/year charges as with mysql), and has a better optimizer.
- oracle is only around $1-2k for a small footprint database. this wouldn't
include partitioning, but at least you'd get a smarter optimizer.
- db2 is around $700 for a 2-way server. this would provide partitioning
(via mdc or union-all views), parallelism, and a better optimizer.
- sqllite is freer (again, no cost), and I suspect has a better optimizer.
So, for $700 once, plus maintenance (18%/year?) you'd have a vastly faster product than MySQL - which can cost you $600/year. And you don't need to talk to a lawyer to figure out whether or not you need to pay for mysql. Or you could get other products that are faster with complex queries and are completely free.
Gosh (Score:4, Funny)
Re:Gosh (Score:5, Insightful)
The added features of MySQL 5, if put into the context of the auto industry, would be like a car manufacturer announcing that some of their 2005 models would now come with airbags and anti-lock breaks. Yes, it shows improvement, and yes, it may plug some longstanding criticisms, but in the larger picture it still means that company is years behind everyone else.
MySQL 5 would have been a great advancement to put it in serious technological competition with other databases...if it had been released in 1999 or 2000. The reality is that Postgre is in version 8 with serious Windows support, Oracle is at 10g with gobs of new features 1% of DBAs will use, and Microsoft is in the process of unleashing a major new version of SQL Server onto a world that has done it no wrong. MySQL has only managed to catchup to where the industry was 5 years ago. Everyone else has kept moving.
Real DBA's don't like MySQL for the same reason real web developers don't like IE. They're both behind the times, fail to live up to standards (CSS/ACID), and only got to where they are because of aggressive bundling. IE is "popular" because it's preinstalled and thus used by the average joe who doesn't know any other "internet". MySQL has made sure it is sitting on every free and cheap LAxP host out there, resulting in droves of kiddie web developers whose experience involves a few web tutorial on PHP and MySQL being locked into its heavily proprietary interfaces and dodgy "optimizations".
Re:Gosh (Score:4, Insightful)
They just want to do your average query on a fairly large db, but do it fast, hella fast. They'd rather put MySQL on a fast proprietory filesystem. Stripe and load balance off some fast storage arrays. And just blast away.
Re:Gosh (Score:2)
Re:Gosh (Score:4, Informative)
> complicated schema or fancy features.
then they might want to check out sqllite: a simple and completely free database *without* bizarre integrity problems.
> They just want to do your average query on a fairly large db, but do it fast,
> hella fast. They'd rather put MySQL on a fast proprietory filesystem. Stripe
> and load balance off some fast storage arrays. And just blast away.
if they're blasting away with mysql, then they aren't doing much with the data:
- no parallel query capability
- no memory tuning
- no partitioning
- no optimizer sophistication
In short, unless you've got extremely simple queries looking up small sets of rows - mysql is slow as a pig, and can't compete with the commercial products. Again, if you *know* what you're doing.
And assuming that you're interested in data integrity and are using the innodb database, then postgresql is just as fast. Possibly *much* faster if you're writing moderately complex queries with 5 or more tables.
The idea that mysql is fast is a myth that came from php kids playing with a database for the first time. Once you actually compare the products available today mysql has nothing going for it - except quite a lot of inexperienced fans. Which, I have to admit, is probably worth quite a bit.
Postgre? (Score:2)
not Postgres (Score:5, Informative)
Actually, "Postgres" is was a precursor to "PostgreSQL". The database started as a university research project called Ingress. A follow-on version was called Postgres (i.e., Post-Ingress). SQL support was added later; thus PostgreSQL (Postgres + SQL).
Re:Gosh (Score:5, Informative)
Re:Gosh (Score:2, Funny)
The past week or so I've been learning PHP and SQL (web tutorials of course, why the fuck would I buy a book on it), and working on my site (which is hosted on my PC, using apache).
Here I thought I've been actually learning something, and growing an appriciation for web developers (and developers in general), but according to you, I'm just a kiddie? Fuck you. It's people like you who drive away "normal" people from actually being interested in things like this. As for mySQL, yes I used it b
Re:Gosh (Score:2)
Here I thought I've been actually learning something
You may be learning the rudiments of SQL, relational databases and a web templating system, but you need to be aware of the limitations and quirks of MySQL. Too many people are leaving college having only used MySQL, and end up perpetuating the myth that MySQL is particularily fast in all but the simplest applications and that the missing features are somehow "unnecessary" in all circumstances. That last thing is what fucks me off about MySQL. For year
Re:Gosh (Score:2)
Re:Gosh (Score:3, Insightful)
Re:Gosh (Score:5, Insightful)
You're absolutely right. The database should fail to accept bad data. Integrity doesn't mean that the database tries to make an educated guess about what you meant (MySQL does this, and its one of the many reasons why MySQL sucks). It means that the database isn't going to let you insert data if it's not correct. Take the simple case of a foreign key. Your application may be buggy and try to insert a value into a column with a foreign key constraint that doesn't exist in the referenced table. The database should fail your insert, not try to find the closest match to the value you were asking for, or let you insert the value anyway even though it violates the constraint.
The people that defend MySQL's lack of features by saying that you can fix all of the problems in application code obviously do not know what they're doing when it comes to databases. They may truly be smart people, but as soon as they spout such nonsense you can be sure that any DBA that hears it will never take them seriously again.
Re:Gosh (Score:3, Informative)
I'm not even a serious DBA and I know the problems.
I use postgres off and on when I need DB applications. Sometimes an app balances between a bdb hash file and then there are some that do need that extra umph.
Still, that said... there are so many extra little things I had to do when writing code for mysql. Try postgresql and see how much time it saves you. (assumming you don't write your code just like you do for mysql). I haven't touched mysql in a long time and maybe it has changed A LOT.
Anyh
Re:Gosh (Score:2)
Agreed, MySQL's data truncation has been a major problem and prevented it from being deployed on critical apps. However, as of 4.1 most of the connectors out there can convert the truncation warning into an exception, and 5.0 has server modes of varying strictness and SQL stand
Re:Gosh (Score:5, Insightful)
Wait a second. If that's a warning, it means that it went ahead and did it and warned you that it did so. If a connector translates that into an exception, how do you roll back what MySQL already did? Besides, since when is it the domain of the connection software to handle referential integrity constraints?
What's the default, and why would I trust them? MySQL has already proven they don't care what you (the developer) want by doing stupid stuff like trying to set defaults when you don't want them, silently ignoring commands (like when you try to create an InnoDB table on a deployment of MySQL without InnoDB), etc. Given that, my assumption would be that the default of MySQL is not the stricter modes, and even if I did choose them they wouldn't be as strict as you would expect.
I'd call it a generous understatement, personally.
Data and referential integrity is not a "feature", but a requirement (if it's not a requirement for you, you don't need a RDBMS). Other features may not be that important, but they're still nice to have for the one or two times you need them. PostgreSQL is free if price is a concern, and there are plenty of other free DBMSs with varying levels of functionality out there.
Really? Postgres -- fully functional, powerful RDBMS that routinely competes with the Big Boys in terms of speed and features, but has a funky maintenance system (vacuum) and doesn't run natively on Windows. MySQL -- toy database propelled to stardom by open source fanaticism, notoriously unstable, its vaunted speed only applies to relatively small, simple datasets (let's hope you're not doing something crazy like a join!), with arrogant developers who tell their users that they don't need certain features ... right up until the point that they implement the feature and then pretend they never bad mouthed it (yes, that's right, the developers did say that you didn't need row-level locking and transactions because you could do everything you need with a table lock and some programmer "smarts"). Sounds like a wash to me.
In comparison to Oracle, Postgres is trivially easy to configure. It also has a very large (but not as vocal as MySQL's) community, and it's not very heavyweight. If anything, MySQL is slowly converging towards Postgres, but it's doing so in a distinctly MySQL sort of way -- deny, deny, deny right up to the point you implement the feature. Because foreign keys will make you slow!
Re:Gosh (Score:2, Informative)
Actually, autovacuum has been around for awhile, and the native Windows version of PostgreSQL started with 8.0
What possibly could anyone have against MySQL? (Score:3, Funny)
Apparently not (Score:3, Interesting)
I can think of a pretty big plus in the column... (Score:3, Informative)
Will it dethrone any of the biggies? Not for a long time and not without improvement.
We're not talking the timescale for Linux to take ground in the desktop war, since databases are already technical... there isn't that 'learning curve' from the user (well, there is, but the 'user' shouldn't be as terrified as a Windows user switching to Linux)...
Re:I can think of a pretty big plus in the column. (Score:4, Informative)
Re:I can think of a pretty big plus in the column. (Score:3, Informative)
Re:I can think of a pretty big plus in the column. (Score:3, Informative)
Re:I can think of a pretty big plus in the column. (Score:2)
they do this by making the client access libraries GPL. whether linking against a GPL lib dynamically brings your app under the gpl is not very clear but there are enough people saying that it does that most would rather not take the risk.
theres also the issue of what distribution is, is distributing
New features (Score:5, Informative)
* capacity for very large databases
* stored procedures
* triggers
* named-updateable views
* server-side cursors
* type enhancements
* standards-compliant metadata (INFORMATION_SCHEMA)
* XA-style distributed transactions
* hot backups.
Re:New features (Score:2)
Any word in improvements to replication? Specifically merge (multi master) replication and sliced (replicating sub sets) replication?
Re:New features (Score:2)
Re:New features (Score:2)
Before: website.com/path
After: website.com.nyud.net:8090/path
Actually, as I'm behind a corporate firewall that _doesn't allow ports other than 23 and 80_ I'd rather they didn't...
Re:New features (Score:5, Informative)
Re:New features (Score:2)
Oh...Wait...
Yay for MySQL (Score:2, Interesting)
Re:Yay for MySQL (Score:2, Interesting)
I started using the ByteFX provider, reporting bugs on sf.net and whatnot because it was licensed under the LGPL. Then
MySQL != SQL (Score:5, Interesting)
It supports most of SQL syntax, so SQL gurus will find it easy to learn. Most of basic SQL stuff works. But more advanced constructs like nested queries are either unsupported or terribly unoptimal, and some SQL features are there just for compatiblity sake but shouldn't be used at all. Instead you should learn and use a bunch of MySQLisms that aren't found anywhere else and do the same thing, much better (faster, safer, bug-free). So if you have a database app and ponder what database to integrate it with, choosing MySQL means more than plain tweaks. It may mean deep hacks. MySQL is devilishly fast when it comes to simple queries. Few databases can beat it in this domain. But it comes with a cost, shortcuts taken prolonging/breaking many other tasks. So choosing MySQL is a dangerous choice - it's a lock-in.
Re:MySQL != SQL (Score:3, Insightful)
Re:MySQL != SQL (Score:4, Informative)
In both cases, you want to look before you leap. Do some trials to see how long porting will take before giving a time estimate, test the new system thoroughly (although that's recommended practice for switching RDBs anyway).
That's not to say MySQL is the only platform where you risk lock-in. Database triggers can be hooked to implementation-specific things, for example. Unfortunately as with programming there are trade-offs to be made between optimization and portability and if you're pushing lots of tuples you opt for the former.
Re:MySQL != SQL (Score:2)
You should treat your SQL queries as a language. You can use the run of the mill translation libraries that way.
When you think about it that's exactly the problem, translating from one language to another. Lucky for us that problem is common enough to have gotten plenty of attention.
Re:MySQL != SQL (Score:5, Informative)
Re:MySQL != SQL (Score:2)
Re:MySQL != SQL (Score:5, Insightful)
It can be done if you do something simple, like say, a forum, but for anything large, advanced features are incredibly useful, and will make sure you're dependent on that specific database.
For instance, it's very desirable to have everything in a stored procedure. Not only this gives a performance benefit, but it also increases security. Building your database this way you can ensure that nobody will ever be able to insert bad data. But the price of that is that converting to a different DB will be really difficult.
Re:MySQL != SQL (Score:3, Insightful)
Placing extensive amounts of business logic in SPs can lead to fractured code bases and schizophrenic systems, vendor lock-in, reduced scalability, extremely difficult debugging, and porting/cross-platform problems.
If performance is so critical that SPs can make or break a system, then you should probably consider changing the architecture by adding application tiers.
Re:MySQL != SQL (Score:3, Informative)
IMO, for instance, it doesn't make much sense to write code full of page-long SQL queries. Not only it looks ugly in the source, but it also introduces potential problems when you find out somebody is using an ancient version of the application that does something wrong.
If your code to create a client is inside a stored procedure, you have several advantages: SQL is in the database, where it belongs. Any bug fixes can be instantly applied to everybody who uses
Re:MySQL != SQL (Score:2)
ORM tools, like Hibernate and TopLink, allow you to map objects to relational tables, and generate the SQL on the fly. (Hand-tuning is still possible, though you would not put hand-written SQL in code, but in some kind of a properties file that is loaded at runtime.) Hibernate, for example, supports a variety of SQL "dialects", which it uses to generate SQL that is compatible with the vendor that you (or your customer) chooses to use. You sh
Re:MySQL != SQL (Score:3, Informative)
Hibernate and ActiveRecord don't run EXPLAIN plans on queries. If you've ever looked at some of the SQL generated by hibernate, it can make you cringe. We created indices to match what hibernate was using only to move the logic into an sproc to get the performance we re
Re:MySQL != SQL (Score:2)
Re:MySQL != SQL (Score:2)
I get the feeling alot of times that many ORMs lull the developer into a false sense of security. I can't count how many times our DBAs have heard "This part of the application is performing slow" only
Re:MySQL != SQL (Score:2)
Re:MySQL != SQL (Score:2)
Re:MySQL != SQL (Score:2)
Stored procedures have a place, but it's not a very big one in the vast majority of projects. I have to question the architecture of any software that makes extensive use of stored procedures.
Re:MySQL != SQL (Score:2)
By the way, although it's extremely common for VB developers to embed SQL into their code it's not considered good programming practice.
Re:MySQL != SQL (Score:3, Insightful)
The only time SPs are significantly faster than ad-hoc SQL are when the two are different. Every database worth a crap today implements ad-hoc batch caching. That means that SQL blocks
Um, no, not really (Score:2, Insightful)
As somebody who maintains the database abstraction layer for a very complex enterprise application platform that runs in Oracle, SQL Server, and DB2 (the latter of which I was the primary porter), I don't think you're right at all on this point. It is possible t
Re:MySQL != SQL (Score:2)
AFAIK, the closest thing to pure ANSI SQL compliance is SQL Server, which is pretty limited as far as very large databases go. How is the above different from, say, Oracle? Orachle uses non-standard CLOBs, sequences, connect by, doesn't do "join" syntax (or was join recently added?), etc.
Re:MySQL != SQL (Score:2, Informative)
It's a relational database, all right
Careful.. MySQL (and PostgreSQL and Oracle) are *SQL* databases. The relational model is quite different from SQL.
Example: in the RM, every value for a given attribute (column) must be of the same type. In SQL, some values can be "NULL" which is a special value, not drawn from the type.
Example: in the RM, attributes are unordered. In SQL, attributes have a consistent left-to-right ordering (this violates the Information Principle which states that all data must b
Re:MySQL != SQL (Score:2)
To be precise, it only partially complies with the relational model, and doesn't really support SQL, which doesn't comply with the relational model either.
We chose Postgresql (Score:5, Interesting)
Re:We chose Postgresql (Score:5, Insightful)
Triggers are queries that are run automatically when the associated table or view is changed. It's generally considered to be a bad practice to overuse them, but they have a few very nice uses.
One is implementing complicated checks. You can make an update query fail if any fields don't meet arbitrary requirements. That's good because you can use that to ensure that everything inserted in the database makes sense.
Another is logging. You can easily make a trigger that inserts the previous content of a row into a different table. Can come really handy for debugging, or when you simply want to easily make sure any changes to some data can be tracked. Also handy if you not only want to deny access to something, but also record somewhere that somebody tried to touch it.
Another use can be gradual redesign. If you're phasing out a column, you can do it in steps: Removing its usage from the latest version of your DB interface, and adding a trigger that ensures it has some value that doesn't confuse older versions. This can be used to provide smoother upgrades.
Locking is a major problem. In a database locks must be placed on data to maintain the consistency. You definitely don't want a database that locks the whole table without a really good reason, because as soon as table locks start happening, your performance goes to hell, as everything else will have to wait.
Re:We chose Postgresql (Score:3, Informative)
One thing prevents me recommending it at places I work is that when I want to do a count(*) on very large datasets (not just entire tables) the response time goes through the roof. This seems to be because table statistics are only updated when the database is vacuumed rather than maintained in an ongoing fashion.
There are various work arounds involving triggers, updating sequences, and estimates based on last statistic upd
Re:We chose Postgresql (Score:3, Interesting)
InnoDB has the same behaviour:
http://dev.mysql.com/doc/mysql/en/innodb-restricti ons.html [mysql.com]
"InnoDB does not keep an internal count of rows in a table. (This would actually be somewhat complicated because of multi-versioning.) To process a SELECT COUNT(*) FROM t statement, InnoDB must scan an index of the table, which takes some time if the index is not entirely in the b
Re:We chose Postgresql (Score:2)
Yes, count(*) does seem to get used a lot in web apps, and web apps are nearly 100% of my work these days. It's a shame because Postgres feels so much more like a 'real' DB than MySQL! I can't tell a client, "Sorry, but we can't run that query in your app... it will just take too long", they are going to ask why, and how I can provide that data they want. I thi
An honest question. (Score:2)
It's simple (Score:3, Insightful)
This is one of the reasons why it is so much more popular than PostgreSQL. Another reason is that around the time of PHP taking off, 1998 or 1999
Re:We chose Postgresql (Score:2)
I can tell you some nifty stories about FoxPro and dBase, and they are database yarns as well. But this post was about a new version of MySQL... which your comment really had nothing to do with... unless I'm missing something.
--
Avn
new feature... Hot Copy ? (Score:2, Interesting)
Re:new feature... Hot Copy ? (Score:2, Funny)
innodb and fulltext? (Score:4, Interesting)
Re:innodb and fulltext? (Score:3, Informative)
In progress: Add FULLTEXT indexes on InnoDB tables. A sponsor for this project has been found, and a developer has been hired. Appears probably in 2006.
Liked it, but don't use it anymore (Score:5, Interesting)
Most other decent databases use something similar to LGPL for use of their libraries, thus there is no need to disclose your source code in an application that uses the database. This is rather a critical feature identified by almost all database vendors. Even Microsoft SQL has an LGPL-like license that doesnt mean you have to share your code.
Once MySQL was reaching critical mass, they decided to change the rules and restrict the license. PHP and others revolted and dumped MySQL for SQLite as the default database for PHP 5. Some could argue it was due to library mixup hell, with multiple versions of libraries on the system, but we all know the main reason was behind the license.
MySQL got a bit scared and made this silly license exception to the top 20 FOSS projects (don't quote me on that, recalled from memory) so they could be LPGL.
In the process I moved all my code to PostgreSQL and havent looked back.
Re:Liked it, but don't use it anymore (Score:4, Insightful)
I use mysql and love it. Not only are the availability and price unbeatable (it ships with my OS, how much easier could it get?) but the performance is truly outstanding. Predictably though, the mysql-bashers who are stuck in 1998 will arise to tell us how mysql can't do subqueries, or has no transactional integrity, or whatever other fairy tales they might dig up at random
Why can't we just admit that mysql is a useful tool in many situations, and move on?
Re:Liked it, but don't use it anymore (Score:2)
Here are three cases, among others, where I can't use Postgres or where Postgres is not the best solution: a) running database server natively on Win9x; b) embedded database manager; c) non-MVCC operation (e.g. due to high update+delete frequency). While these points can be argued (e.g. embedded is not the safest mode of operation, etc), there are people who want and/or need them.
There are other points/cases like availability of host
Re:Liked it, but don't use it anymore (Score:2)
yeah, they picked SQLite because they had problems with MySQL and postgresql. I think it's very telling that they didn't pick postgresql.
Re:Liked it, but don't use it anymore (Score:2)
Even in the open source world, sometimes these decisions are a
Re:Liked it, but don't use it anymore (Score:3, Insightful)
but i was simply responding to OP's chest thumping about how php "ditched" mysql because the license was so evil. and his smug "but we all know the REAL reason they switched, wink wink nudge nudge" comment.
to OP, PHP moving to SQLite can't possibly be due to technical reasons -- it's due to ideological ones. so he's using it to justify his ideological switch to postgresql.
as you pointed
Re:Liked it, but don't use it anymore (Score:5, Informative)
I call your bluff. Here's the entire, unedited PostgreSQL license (source their website [postgresql.org]):
Where's this advertising clause you speak of? Or did you hear "BSD license" and drag out a decade-old complaint that's long since been addressed? That's as bad as people complaining that MySQL doesn't support transactions, except that's true under certain circumstances whereas your criticism is completely unfounded.
Re:Liked it, but don't use it anymore (Score:3, Insightful)
Re:Liked it, but don't use it anymore (Score:2)
Re:Liked it, but don't use it anymore (Score:3, Insightful)
3 words... (Score:3, Insightful)
Changing indexes causes entire table copies! (Score:2, Informative)
Even with relatively I/O beefy machines this means hours of production outage for tables with just millions of rows. A nightmare for any critical application.
I've used MySQL for a year after Sybase, Oracle and SQL Server and would definitely agree that optimisation for anything but the most trivial queries generally s
5.0 is Mission Critical, eh? (Score:2)
The article profiles mission critical database software and discusses how well MySQL 5.0 fits the profile.
I love MySQL - I've built my technical solutions around it for the past 5 years. However, until it's released for PRODUCTION use you can't call it "MISSION-CRITICAL".
See http://dev.mysql.com/doc/mysql/en/choosing-version .html [mysql.com]
Only Problem (Score:2)
As usual, little of MySQL, as well as most other DBMSs, properly supports the relational model, according to Chris Date and others.
It's nice to see MySQL getting stuff other DBMSs have had for years, like triggers and stored procedures, but for uses other than a replacement for file managers like Access and for DB-backed Web sites, go with PostgreSQL or Firebird or others with a little more power. Messing with database designs for mission-critical needs can land you in hot water fast with a product that doe
I think not (Score:4, Interesting)
Having said that, anyone who says that MySQL are ready for 'prime time' are clearly deluded. You can have a database server with unbelievable speed, features, security and stability, and it doesn't mean a damned thing if you don't have client libraries ready.
MySQL's client libraries are appauling. MyODBC, their ODBC connector, has been one big fuckup after another for the past 2 years. It's a minefield of:
Rock up to a MySQL mailing list, and the most common questions is about client libraries and the 'new' authentication system. The problem is that this authentication system is no longer new - it's old. It's many years old. Why haven't the client libraries been updated? The error message suggests that users "upgrade their client libraries", but upgrade to WHAT? Perhaps the error should read:
I for one would prefer to see some actual client-side support for 4.1.x before people start declaring 5.0.x 'ready for prime time'. You can't use 5.0.x features with 4.0.x libraries.
Has anyone checked out the GUI admin tools? These are also a long chain of distasters. MySQL seem to spend 18 months getting a GUI looking promising, if a little buggy, and then abandon the project. What happened to mysqlcc? What's happening with Administrator / Query Browser? Critical bugs reported months ago have gone completely untouched. For example, you can't edit tables with a primary key, because Administrator doesn't recognise the primary key, and strips it out of the table when you click 'apply'. Cool! Sounds ready for prime time to me! When will MySQL add support for primary keys to their products?
Yes, I'm stirring here. But none of the above is in the slightest untrue. MySQL have lost their focus. With so much attention being paid to a 5.0.x release, everything else is suffering badly.
Re:I think not (Score:3, Insightful)
Re:I think not (Score:2)
MySQL's client libraries are appauling. MyODBC, their ODBC connector, has been one big fuckup after another for the past 2 years.
The horrible JDBC support with MySQL was the final straw for me, and what pushed me to PostgreSQL for all of my new database backed applications. The PostgreSQL JDBC drivers work really well, especially in the presence of Unicode text data. I've heard that more recent MySQL releases have better handling for this, but it's too late for me.
Has anyone checked out the GUI admin
From personal expereince... (Score:5, Interesting)
It just doesn't cope. It's fine if you've got no data to speak of; it's great when the sizes of what it's working with is small.
IT TAKES 24 HOURS OF UNWRITABILITY TO MAKE A DAMN BACKUP, FOLKS.
MySQL was the biggest mistake I ever made. I had the option of choosing Postgres on an older version of the software, or MySQL on the latest, and I've been regretting it ever since.
The fact is this: I've used it for stuff when the amounts of data are small, and it's brilliant - but if you need to keep a lot of information, you're screwed - run, don't walk, to the nearest vendor and get something decent, because MySQL just can't cut it. It's missing too much in too many places.
Now, I haven't used 5. I'll have to, because 4 sucks, and 5 can't be worse - I can only hope that 5 gets rid of the worst of my problems; it will probably stay slow and unresponsive, and continue to take an hour to generate a report, but I can at least pray that perhaps, if I'm lucky, I can get a backup out of it without taking down the system.
No matter how good you think it is; no matter how fast you think it might be... don't pretend it scales up to the kinds of loads the commercial vendors can handle. There's a reason the big boys cost big money, and despite popular opinion, it's not all just leeching money out of your pocket. MySQL doesn't do big well.
MySQL AB = Proud SCOX business partner (Score:2)
Then I see the announcement of the business partnership proudly displayed on mysql ab's website.
Disgraceful.
Really? (Score:5, Funny)
Re:Interesting (Score:4, Funny)
Chapter 3. Ambiguous Comments
As discussed in the previous chapters, gaining a first post can be a difficult task in itself, let alone scoring something above -1, Offtopic. For this reason, it is often advisable to post something relevant to make sure your first post is visible to all who read the comments. This can lead to several problems, namely having to actually read the arti... er.. I mean, having to type a relevant comment quickly enough to beat another first-poster. For this very reason, we have provided a list of easy to use copy and paste ambiguous comments that will slide past your average moderator. Below is a short list of comments, guaranteed to keep your FP above 0. Write them down, learn them off by heart, and most importantly, keep them in your clipboard or in a notepad window so you're ready to paste and post as soon as your NST (New Story Checker© - Provided on CD) alerts you to a new post.
I'm sure you can think of many more.
In the next chapters we will cover the popular slashdot jokes guaranteed to get you those 5, Funny scores to impress your friends, and the best way to change your signatures to GNAA related text once your posts reach 5.
Re:MySQL? not mine! (Score:2, Insightful)
Re:down with MySQL (Score:2)
I have used and tested both; for *every* query that I tried PostgreSQL is either faster or as fast as MySQL. For some complex self-joins for tree-queries PostgreSQL finished within a few seconds where I stopped MySQL after 30mins (and yes I check all the indices, etc).
Since PostgreSQL has to spawn a new process for each connection - as opposed to MySQL which only spawns a new thread - there extra overhead involved in o
Re:Moving from one DB to another (Score:3, Insightful)
If the dev team wants to develop using a different DB than productio