'Most Important Ever' MySQL Reaches Beta 632
An anonymous reader writes "The open source database company says it is 'fixing 10 years of critcism in one release', and is aiming at boosting enterprise take-up." Stored procedures. Triggers. Views. It's like it'll be a real DB!
Most Important Ever? (Score:4, Funny)
Re:Most Important Ever? (Score:5, Funny)
clearly that was firebird
(not fp) (Score:5, Funny)
Re:(not fp) (Score:5, Informative)
Re:(not fp) (Score:5, Funny)
Re:Come on stop whining! MySQL is SUPER! (Score:5, Insightful)
The integrity problems are specifically because of poor implementation of foreign key and other constraints. Read up at http://sql-info.de [sql-info.de] or a million other sites on the net. There are fundamental problems in their implementation. It doesn't matter if you are using transaction isolation or innodb tables, MySQL silently changes data in many many circumstances. This is bad.
My 'users' aren't touching the database design. The database developers are. Multiple developers. When one makes a change and goes off shift, the next guy working on the table should immediately know if something changes made by the previous developer have invalidated some new data/scheme he's implementing. A database should never silently accept errors. It should always flag someone and refuse to make (or appear to make) a bad change.
I don't know about your background, but a lot of MySQL users haven't a clue how a real database should be designed or what real data integrity is. I'm not bitching about MySQL not having features, I'm bitching about it's shoddy implementation of the features it already has. Foreign keys (in innodb) do not work right! Constraints do not work right! Many other basic features that MySQL claims to have do not work right!
I'll say it again: A database should protect your data. It should not silently change data it doesn't like, instead of aborting the transaction and throwing proper error message.
Postgres is also available for free. And it's designers appear to care about data integrity.
foreign keys? try write-ahead logging (Score:5, Insightful)
Re:foreign keys? try write-ahead logging (Score:4, Interesting)
Re:foreign keys? try write-ahead logging (Score:3, Informative)
Information? (Score:4, Insightful)
you're kidding, right? (Score:3, Informative)
or just spend 2 minutes on the mysql website and you could have found this [mysql.com].
being a paying customer... (Score:5, Informative)
It's astonishing how far mysql has come. I'd been using 3.23 since before the dawn of time. Like most users of my ilk, I'd hacked alot of "databasish" functions together at the application level. My dilemma now is throwing away all that work to migrate to something I know is better. But there's no doubt that replication, triggers etc are all worth it.
The *best* thing that I got out of the class though, was to talk freely with the MySQL guys about their reality of trying to make a living with a "mostly" free product. They convinced me to buy a membership in MySQL Network [mysql.com] which is essentially support that I probably won't use. This upgrade they are turning out though is good enough to make me WANT to pay (once).
Re:being a paying customer... (Score:3, Insightful)
The one thing that MySQL excels in is raw speed. It's faster than everything else because it doesn't have all the data integrity features that a RDBMS does.
However, I stick everything into the application layer, so MySQL lacking these features doesn't bother me a bit.
As for data integrity; I haven't done a banking application yet, so I'm unconcerned.
Scheduled DB backups and logging in the application layer keeps me from needing any transaction
Re:being a paying customer... (Score:5, Insightful)
Agreed. I don't think other database vendors understand the importance of speed to a Web Developer. We have to go over a network layer, with the requisite delays factored in. We use a client-server model, and cannot rely on the client CPU, like a traditional software product. And even a crappy Web site can find itself loaded down with a large audience. So we have to squeeze out milliseconds anywhere we can get them. A fast database and optimized code, that's pretty much what we can control.
I mentioned this story once before on Slashdot, but it's relevant, so here it is. Borland had a product called Intrabuilder. It had a poor-man's version of Live Script on the backend, with a built-in database -- so back in 1997 you could do some very PHP-like stuff with the system. It was promising. But as a Web guy there, I was tasked with using it on the borland.com site. And it was giving me huge lag -- 1 or 2 seconds per simultaneous user. So with 5 people testing my app, each page took 10 seconds to display. I told this to the Intrabuilder team. Response? "That is an acceptable delay. It's how databases work." For all I knew, they were right. Maybe databases did work slowly like that back then. I was young & new to that stuff. But I knew that I didn't work that way and I didn't want my site to work that way either. Borland eventually abandoned the product, because the developers didn't see the shift in the market: Web Developers need speed. It's not like an ATM transaction, where I'll wait 15 seconds to get my money. MySQL needs to keep its speed, especially under load. And other database teams would be wise to take note.
Re:being a paying customer... (Score:5, Informative)
No. These delays are not parallel, they are serial. In other words, the delays are cumulative, building on top of one another and extending the delays further. If the network, CPU, database, and code each add 500ms lag, that's a 2 second wait for the Web page. By getting the code to a point where it executes in only 100ms, and by switching to a database that can return the query in 100ms, the end-user now waits only 1.2 seconds for the Web page. You may think that the difference between 1 and 2 seconds is insignificant, but that would be the kind of thinking that got Intrabuilder into trouble. I recently had outshine.com move to a new server, and instantly saw visitors to the site decline sharply. Why? Well, the new server was doing DNS lookups on each request, and it wasn't caching the results for more than a second! So nearly every request had a 3 second delay in response. That alone killed off about 25% of my traffic. In an e-commerce site, such a loss would be a disaster.
Re:being a paying customer... (Score:5, Insightful)
So what if the accounting system is off by $12,000,000? It's fast.
Who cares if the customers actually get the products they ordered? It's fast.
Who cares if we bill our customers for the right amount? It's fast.
Yes, because it's so much more professional and a more efficient use of your time and employer's money to hack together a half-assed system rather than learning how to use a tested and proven one that someone else wrote. This statement just demonstrates the fact that you have no clue what transactions are for, or how and when to use them.Re:being a paying customer... (Score:5, Informative)
You seem to be implying that OSS databases make do without transactions. This is incorrect, since PostgreSQL has supported them for a long time (and, AFAIK, so has MySQL, for some table types - I wouldn't know for sure, since I use PostgreSQL myself).
You are correct, with the addition that transactions guarantee that the changes have been logged into permanent storage (disk) when the "COMMIT" command returns.
What happens if there's a power outage in the middle of a some update that requires multiple queries ? Or in the middle of a single update query ? Or if the database server simply crashes ?
PostgreSQL executes each command in as a "mini-transaction" with implied BEGIN and COMMIT wrapped around it (assuming, of course, that the command wasn't already a part of a transaction), which means that if power gets cut in the middle of a command like "UPDATE customers SET DEBT = DEBT + 1", then either all the records are updated or none is. As a result, data stays consistent even when if something unexpected happens - the whole thing works a bit like a journaled filesystem like ext3.
Of course you can work around these kind of issues in the client software, but it's more convenient to let the database system handle them.
Re:being a paying customer... (Score:3, Informative)
Maybe he spent a lot of time cleaning up a legacy (read: developers bailed long ago) database application that was consistantly hitting bugs that wouldn't have existed if the DB had been safeguarding the app layer from screwing up too bad. That kind of experience tends to lead to a fairly nontrivial amount of anger over bad databases (and, worse, refusal of app d
Re:being a paying customer... (Score:5, Insightful)
I've been a DBA for 8 years and i've seen countless developers spend days, weeks programming features that are already in the database. I thought developers loved to reuse code but I guess some like to do everything from scratch by themselves.
I dunno, maybe if you had real dba's to tune the DB rather relying on developers supporting it, maybe you would see the same performance out of the 'slower' RDBMS like oracle, DB2, postgresql.
Personally I'd rather rely on transaction logging, integrity being handled by the database.. Why? Because depending on the RDBMS they've been there a long time and pretty stable. Not to slight your skills but your time is probably better off spent on other parts of your code rather than somethings thats been tried, tested and true.
Re:being a paying customer... (Score:5, Informative)
Hmmm, really? Lets see...
if you're using myisam (the fast io layer), then all locking is done at the table level. Which means that if you get multiple connections attempting to write to the same resource they'll all have to wait while their operations run in series. Fast? Nope, hard to imagine a slower scenario than that.
again, if you're using myisam (again the fast solution), and need to select 10% of the rows of a table with 10 million rows, what will it do? It'll do a scan of all 10 million rows. What would oracle, db2, or informix do? Rely on partitioning to just scan those 1 million rows. Of course, these commercial databases will also break the query up into pieces and run them all in parallel across multiple cpus on your server. You could easily find mysql taking 40x as long to respond to this query as one of the others.
How about if you've got a complex query? Well, mysql admits that their optimizer is very primitive, and will take a while to fine-tune. Great, so now you just write a few different versions of your query until you get the speed you want, probably depending on 'gaming' the optimizer. Then when you upgrade the software next year you'll find that your gaming is killing performance. Time to rewrite the query. No big deal, we all went through this (about twenty years ago, and glad to have it behind us).
ok, how about using their non-isam option. Ok, now we've got the kind of data integrity we've taken for granted since about 1981. But, reads are very slow, often 1/10th the speed of myisam.
On the Innodb site they brag about getting 800 inserts / second. I think the most recent db2 benchmark on a 4-way intel box hit almost 3,000 transactions per second. Note: Not just simple inserts & updates, it was a tpc benchmark. And that's on a low-end box. At the high-end db2 is running 80,000 of these transactions per second.
Fastest? please, only in read-only transactions running on tiny hardware...
Re:being a paying customer... (Score:5, Insightful)
It's faster than everything else because it doesn't have all the data integrity features that a RDBMS does.
I stick everything into the application layer, so MySQL lacking these features doesn't bother me a bit.
So, you use the database because its lack of features makes it faster. But then you reinvent the wheel by writing those features into the application. Surely you realize how likely it is that you are wasting all that speed and more in the application layer trying to do a bunch of stuff that your database is supposed to handle for you. Unless you really think you are so superior to the coders at Postgres that you keep an advantage (good luck), you are wasting your time and adding foolish complexity to your apps for no reason.
Re:being a paying customer... (Score:4, Insightful)
Re:being a paying customer... (Score:3, Insightful)
Ever heard of the "Don't repeat yourself" principle? Putting logic in the application that belongs in the database means that if just one place that touches the data forgets to do what your trigger should have done, you're screwed.
Maybe your applications are small enough that this is an acceptable risk for you. The ones I have worked on haven't been.
Re:being a paying customer... (Score:3, Insightful)
Re:being a paying customer... (Score:3, Informative)
Some of us actually hold the database they use to higher standards, and aren't interested in using middleware hacks to do things that should be the domain of the database engine. If you want to call that a troll, go ahead. There are probably some very complex systems out there using XML files as their data source. But that doesn't mean XML is a good database either.
A good database should r
Re:being a paying customer... (Score:5, Informative)
Or trolling ? Or both ?
Anyway, if somebody is using mysql in any kind of environment, he surely has already heard of this by now unless he's living in a Cave, thanks to all the postgresql zealots.
Re:being a paying customer... (Score:5, Informative)
Why don't you give 5.0 a try? You'll find things have changed a bit. You can startup the server in TRADITIONAL, STRICT_ALL_TABLES, and ANSI modes and get the behavior you want:
Re:being a paying customer... (Score:3, Insightful)
A database is not (to borrow my own phrase) just a flat file with an API. It's supposed to enforce a data model. In a perfect world, every piece of integrity and sanity checking would happen inside the database, with none inside the application layer. A database application that includes logic that looks like "if input is X then reject" is not a good database application.
Re:being a paying customer... (Score:5, Interesting)
This isn't data corruption that throws up a big flag, 'your database file is corrupted and you can no longer access it', it's sometime subtle anomylies in the data. Some of which can be very very bad if you are relying on the data to be good (such as dealing with money, or used in calcuations that you rely on, etc).
I've often had MySQL folks told me they have never had data corruption. Until looking in detail at the real data. Then we've sometimes found it. All it takes is leaving out one tiny constraint check in your application you are writing.
Just because you haven't spotted the bad data, doesn't mean it's not in there. That's why I don't trust MySQL. I want to know the database is keeping the data safe. I want real foreign key and other constraints. Really enforced, with errors thrown up when someone tries inserting bad data. Not just guessing that since I haven't spotted any bad data, there's none in there.
If it's just for use in a blog, sure, who cares. But I generally work with databases where I actually care about the data. Postgres, Oracle, etc is the way to go if you really care about the data.
Re:being a paying customer... (Score:3, Interesting)
Short version: This software, which is maintained by a team of fewer than 20 people, has never failed in the field. It's multiply redundant, but those redundancies have never, to date, been necessary. It works perfectly all the time.
From the time that the first line of code was written back at Lockheed in the late 1970s to the time at the
Re:being a paying customer... (Score:5, Interesting)
Putting data logic in the application is a problem that was (supposedly) solved in the 60s. Apparently some folks didn't get the memo..
You wanna know what the problem with putting logic in the application is? Yup, you (hopefully) guessed it: there are very few systems where only ONE application is guaranteed to modify the data.
Maybe your client goes in with a DB tool to quickly change a value. Maybe the summer hire writes a quick Ruby script to adjust some values. Maybe your client just wants a Java frontend to go with your web app.
Are your constraints well-documented? Are you sure you got them right when you translated from Ruby to Java? Personally, I don't want to even *try*.
I have plenty of "war stories" about this. I'm surprised you haven't run into problems. My first big programming project was an ecommerce database without referential integrity constraints. Sure enough, there was bad data in the DB.. order line-items without corresponding orders. The client had just gone in and deleted them by hand, and had been doing this for 5 YEARS. The problem? Author royalties were paid based on order line-items. So they had been overpaying their supplies, basically, for years.
A bug in your code is easy to fix. A bug in your data means you've got a dependency graph starting from the moment the data entered the database, extending into the future. Who knows what other bad data was produced based on that one piece of bad data? How do you fix it? How do you rollback/replay ALL your data changes??
You MySQL lovers can crow all you want. Frankly I don't know why you would pick a DB with less features when others are freely available with the same cost, but whatever. Until it's possible to build a system in MySQL that doesn't allow bad data, those of us who *really* know what we're doing won't touch it, even for throwaway projects (I've got plenty of war stories about prototypes that are still in production use too).
On second though, considering how many consulting dollars I've made fixing broken crap, go right ahead...
Re:being a paying customer... (Score:3, Insightful)
I'd rather rely on the database to ensure my data integrity as I can be reasonably confident it's been tested a lot more than my code. I can say "make that column unique in that table" and be 99.99% sure it will always be unique (let's leave the .01% chance o
Re:being a paying customer... (Score:4, Insightful)
Yeah, but how reliable (read: it sucks) is it?
From TFA:
"I believe it will change how MySQL is perceived in the market," said Axmark, who then added that he thought this release would make MySQL an option for at least ten times as many users as before."
It says in the article that mySQL has a 40% share in the open source DB market. If they're gonna get 10x as many users, that'd be 400%, so I guess they plan to make further gains in the commercial market.
If open source DBs have a 10% share (means shit, anyway), then mySQL plans to shoot from a 4% to a 40% market share. I just don't see that happening.
About the market share: what does that mean - 40%? Of what? By number of copies in use, by data, by number of paying customers...?
Re:being a paying customer... (Score:3, Insightful)
100,000 or those are open source.
40,000 are MYSQL.
so they are shooting for 10X meaning 400,000, this is obviously impossible for them to obtain that many users. But do note he said it makes MYSQL an "option". This means that 40% of database users require the features that MYSQL now has and nothing more. I can believe that.
Utopia? (Score:4, Insightful)
If they can fix 10 years of criticiscm in one release, why couldn't do that before? Or maybe in several fixes rolled out within the 10 years?
Re:Utopia? (Score:5, Funny)
They just pulled an all-nighter, dummy! (Score:5, Funny)
ex-EA'er: "Can I get 3 whole months to do 10 years of wish lists?"
MySQL management: "Take your time- have 4!"
"WOW....! You're the best boss a guy could hope for!~sniff~"
Re:Utopia? (Score:5, Insightful)
> several fixes rolled out within the 10 years?
If you recall, their management made the (unconvincing) argument that 99% of the time people didn't need fluff like:
* referential integrity (pk & fk constraints)
* views
* triggers
* stored procedures
So, they never implemented this because they had been arguing that nobody needs it anway. Nevermind that it's been standard fare for over twenty years.
Personally, although I'm glad to see them support views, I would rather have them clean up their exception-handling than add triggers & stored procedures right away. The problems with silent errors, silent truncation of strings & integers, date validation errors, etc are far more serious than what they are adding in this *beta* release.
Maybe in five years that'll be the release that fixes 15 years of criticism?
This isn't just "customer base changed" (Score:5, Interesting)
Here's what the MySQL docs (source: http://web.archive.org/web/20000619203550/http://w eb.mysql.com/Manual_chapter/manual_Compatibility.h tml [archive.org]) used to say about foreign keys, for instance:
Re:Utopia? (Score:3, Funny)
(Just because you are uninformed and don't know what other things are, doesn't make what you are doing 'right' and that they shouldn't be done better.)
Meanwhile, back in 3.23.x land... (Score:5, Insightful)
Re:Meanwhile, back in 3.23.x land... (Score:5, Insightful)
Thats because a lot of people who 'run web hosting companies' know jack about administration, security and what their users really want, and are just jumping on the internet business bandwaggon.
It's sad to say, but now with products like Helm, Ensim Webppliance etc. anybody can run a hosting business.
Anyway, to get to my point (and the end of a rant), because there are a lot of webhosts detatched from 'all that funny dos stuff at the backend' upgrading to newer versions of services etc. can be non-trivial if there isn't a button on their control panel to do it.
If you have any spare time and want to see for yourself, go traul through the CPanel message boards for threads you'd expect from a unix green-horn, but are actually coming from admins of supposidly 'reliable and respected' hosting companies.
While it will be a few months into the mysql 5 general release before you start seeing it being used in the hosting industry (I know several people who are just switching over from 4.0 to 4.1), the benifits for developers will be great (in the long run).
I expect to see a new batch of commercial and open source development spured by the growing stability of mysql 5, but also an increase of help requests from newcomers to web development.
Btw: I think there should be a new moderator option.. Rant -2
Re:Meanwhile, back in 3.23.x land... (Score:5, Informative)
MySQL (Score:5, Funny)
So, the Slashdot editor, whose own Web site uses MySQL, is actively trolling other MySQL users in the article summary? Hilarious!
Re:MySQL (Score:5, Funny)
Sarcasm not accepted around here (Score:5, Funny)
That's right, everyone at Slashdot hates and fails to understand sarcasm. Except moderators. Those guys love the stuff. They eat it up and mod funny things "funny" even though the sarcasm they perceive isn't really there, and the comments are just trolls or flamebait.
Sounds like troube brewing (Score:5, Insightful)
I love MySQL, and use it, as well as PostgreSQL and Oracle, depending on the project. However, if stability or data integrity becomes an issue because of all these feature additions allowing them to play with the big boys, I'll drop MySQL in a heartbeat.
If your database isn't reliable, it nothing else really matters.
how did this get modded insightful? (Score:5, Funny)
I guess that's one way to make MySQL's "foreign keys are for wimps" documentation look good: anyone who implements more than MySQL does is just throwing stuff together and worrying about debugging later! Never mind that just about anyone else is more standards compliant; the MySQL team are heroes of stability and everyone else is just trying to add features for marketing.
Nobody really needs that ACID crap anyway, and if you say you do, you're just a poseur...
Re:Sounds like troube brewing (Score:5, Insightful)
You forgot the most important part: Tell everybody how they don't need a feature, and how they can work around it with application code, and how adding that feature will make MySQL suck to the high heavens, and you really don't want that now, do you? Then, when they finally do add the feature, act like they've never said anything bad about it before. The endless sniping at the MySQL team is completely justified by their cavalier attitude towards proper RDBMS design, and their insistence that the programmer can "easily" work around their incompetent RDBMS design in his application code. If that sniping has encouraged the MySQL to abandon its "careful development process" in favor of turning MySQL into a real RDBMS, then mission accomplished.
Other DBs (Score:4, Interesting)
Comes with a price (Score:5, Insightful)
"Like a real DB" (Score:4, Informative)
As a data-point:
simon% mysqladmin ver
mysqladmin Ver 8.40 Distrib 4.0.18, for suse-linux on x86_64
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license
Server version 4.0.18-Max
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket
Uptime: 5 days 21 hours 32 min 52 sec
Threads: 2 Questions: 103591631 Slow queries: 101 Opens: 181809 Flush tables: 1 Open tables: 64 Queries per second avg: 203.291
Simon
get over it already (Score:5, Insightful)
popularity isn't proof of clue, guys. How many people run windows, right?
with postgresql and firebird there have long been available real open-source databases that are just as easy to get up and running as MySQL, but won't hamstring you when you start to learn more.
I'm glad to see MySQL joining the club, but it must be shocking for the "we don't need no steenkeeng logic in the database" fanboys to adjust... Parent is case in point, I guess.
Re:get over it already (Score:5, Informative)
No. If that were true, then they would have seen far greater adoption rates. PostgreSQL has a history of difficult installations -- I tried it years ago and was stymied, then tried it again in 2003 I think and was stuck doing VACUUM (sp?) over and over. It also had some byte-size limits, but I don't think I even understood that complaint or experienced it. In the meantime, for MySQL I just hit "install" and it did, with excellent defaults, so that I did not need to babysit it at all.
And as for Firebird, no. I worked at Borland, I saw the limitations [slashdot.org] of that monster. I'm not suggesting that Firebird is problematic now -- I suspect it is devoid of problems to the point that I'd prefer it over PostgreSQL. I am merely disputing your assertion that it has been "just as easy" as MySQL. It hasn't. It may be now. But now may be too late.
Also note that I am not suggesting that MySQL is perfect. But let's focus on legitimate complaints, such as the way it quietly recasts data and stores it, rather than error out. For example, storing dates as 0000-00-00 when your table setup did nothing of the kind. Once that little (in)convenience introduces itself to you for the first time, you really wish you had been using PostgreSQL. Of course, again, it looks like a "compliance" mode is being integrated into MySQL, so by the time I'm ready to ditch MySQL over this, they will have fixed it, and I'll stay. :)
postgresql 6.x is long gone... (Score:3, Insightful)
If we talk about 7.x and if "./configure; make install; initdb; set up cron job to run vacuum" makes postgresql hard to install I guess I was wrong, but if it does your threshold of "hard" is going to cause you a lot of pain.
Re:get over it already (Score:3, Insightful)
Fair game (well, was fair game, anyway). Now consider this:
If you are converting from another commercial database to either MySQL or PostgreSQL, which do you think will be the more difficult install? My bet is you'll be weeping with MySQL.
It's easy to say MySQL is an easier install when there's not data or application code. PostgreSQL becomes much more viable once you already have working code.
So? (Score:4, Insightful)
Also works well enough for "most purposes": Flat files, MS Access, etc. That doesn't mean I'm going to build any kind of important app around them.
Re:InnoDB is ACID-compliant. (Score:3, Interesting)
Isn't that what wikipedia was running when they had their database corruption due to a power outage that caused them to have to replay the whole thing from backups (minus whatever transactions were lost)?
So it gives you transactions, possibly consistency. It doesn't seem to provide durability.
Short of a block on a hard drive no longer being readable, I can't see how
Who's still using mysql? (Score:4, Interesting)
It's great for prototyping things, but i just can't imagine running something critical on it.
Comment removed (Score:5, Informative)
this is advertorial (Score:3, Interesting)
This blurb on Slashdot is an advertorial. There's absolutely no real meat to the ZDNet article. It's got one quote from a guy at mySQL mentioning three new features. The older slashdot story pointing to the changelog at mySQL [mysql.com] has way more information than this ZDnet piece. And it doesn't conveniently feature a big banner ad for SUN hardware.
It was submitted from an anonymous reader. I am betting that anonymous reader is a sales guy at ZDnet looking to boost hit reports for their Sun banner ads. "I'll ca
Most important evar!! (Score:4, Funny)
Bugfest (Score:4, Insightful)
Everything in one release? (Score:3, Insightful)
Plus, are they following the ANSI standards for the features that have them? If so, they are going to break compatiability with prior versions.
I would wait until atleast version 5.1 before even thinking about using it.
BWP
Real DB? (Score:5, Funny)
Then what will Slash use?
Re:Real DB? (Score:5, Funny)
Re:Real DB? (Score:4, Funny)
Wake me up when it goes to production. (Score:3, Insightful)
Normally I put in beta software on my box (never in any production units, mind you... just my own personal box) just to "kick the tires" and see whether a new version of an app or some new piece of technology is going to get the job done.
But not databases. I won't even mess with alpha, beta or even release candidates of ANY database software until it is RTMed or "gold". It's gotta work and work right, or there's no point messing with it. I don't want any suprises with database system issues when working on any projects... not even in the earliest development stages.
I'd just as soon see that MySQL take thier time and get 5.x released when it is ready. And when it is released, I hope it works RIGHT.
Article unreadable (Score:5, Informative)
At what cost? (Score:4, Interesting)
I do hope all these new features are either off by default or easily turned off.
Firebird more popular than Postgresql? (Score:4, Interesting)
"It [MySQL] accounted for 40 percent of open source database deployments, while Firebird and PostgreSQL accounted for 39 percent and 11 percent of deployments respectively."
Are these stats really true? Despite being a firebird user myself, I'd always assumed postgresql was a much bigger, more widely used product.
Unless of course the author is including *all* databases based on the Interbase code in that percentage?
Re:Firebird more popular than Postgresql? (Score:3, Informative)
Evans pointed out in their release that 90%+ of the respondees did their development on Windows. At the time of the survey, there was no PostgreSQL release version native on Windows. Further, Evans specifically surveyed users who use open source. PostgreSQL doesn't account for 11% of t
well (Score:3, Interesting)
MySql a.b. have previously shown their willingness to change their license terms and this has manifested itself in issues with projects like PHP who notably have changed to pushing SQLite more heavily with PHP5.
The biggest problem is not technical (Score:5, Interesting)
There where 3 reasons why MySQL got popular:
* Free
* PHP
* Windows support
Free has been removed because fo the license change. PHP is a non-issue, these days, and naitive Windows support is now in PostgreSQL 8.0.
Now, we have a much more level playing feild. On brief analisys we have:
* Easy replication on MySQL/ Not so easy on PostgreSQL (when only soncidering the free varietyfree)
* Experimental/new features on MySQL, but throughly tested features on PostgreSQL.
* Limited license on Mysql, BSD license on Postgres.
Those three are, IMHO, the remainging differences pertinant to typical DBS selection.
Then there are the addional features. I like the sandards-compliance and no gothcas (MySQL Timestamp) of PostgreSQL.
Just my $0.02
Re:The biggest problem is not technical (Score:5, Informative)
Go ahead and click on any of the links on that page which describe bugs fixed in a release of the many branches. In almost every one, there's a critical bug that causes replication to fail, turn itself off, crash mysql, or otherwise act in an unpredictable manner. We've wanted to use it for two years now, but every release has some terrible flaw that makes this impossible.
Heck, they've only recently fixed a bug in the 4.0 branch that's been there since at least 4.0.12 which caused mysql to silently segfault and restart itself. Not to mention the bug before that, which segfaulted, restarted mysql, and randomly corrupted open tables. 4.0 is just now getting to the point where I'd recommend it to other people. I won't touch 5.0 with a mile-long pole until it hits 5.0.20.
Re:The biggest problem is not technical (Score:3, Insightful)
Re:The biggest problem is not technical (Score:3, Informative)
3 Allowed MySQL use where MySQL was used to fetch and organize data that was already availible through other means. Not only did we have a sequential text-log of all the data, but by running MySQL in parralell and doing some parsing and storing offsets of where the data was in the file, it greatly simplified searching.
v4 not only prohibited that, but it forbids use in any commercial envir
NOW IT'S READY FOR THE ENTERPRISE!! (Score:5, Insightful)
Copied from my blog^Wweb based journal.
Once you start getting into "serious" work, or "enterprise" level computing, which is all anyone argues about, every single assumption gets tossed out the window.
Thought your OS was stable? Yeah, it's pretty stable, but when it gets hit all day every day at 100%, it crashes for some reason every few months. I'd love to say that Linux is the exception here, but well, it isn't.
Maybe you bought the highest quality disks? And avoided the "bad" vendor? Wrong! This year the bad vendor is the one you bought plenty of! Looks like your recovery plan didn't consider that 25% of your disks would fail in the first year!
Thought you had enough RAM? You don't! And you can't add more because you're on a 32-bit platform. Sucker! Start migrating to 64-bit and learn a whole new bunch of gotchas the hard way.
Hey! This RAID adapter has an awfully funny glitch! When you pop a brand new disk in, if you reboot, it treats it as a whole new array, and the funniest part is that it renumbers all of the other arrays! Kernel panic: can't mount root device! What a laugh! Good thing we have RAID here to give us added reliability!
Thought you'd never max out that fridge computer? Well, you just did. It looks like your developers decide to get sloppy when they think they have infinite capacity. A couple of weeks of performance analysis and retuning the algorithms instead of doing real new work!
Thought that replication setup would scale infinitely? Well, infinitely actually means 10,000 queries/sec. Yup, that's the ceiling. No choice now but to re-architect the whole system into a decentralized dataset. Hey, since it's all so decentralized, lets just store CSV files! Added bonus: management types love it!
Six months of re-engineering to decentralize the whole system, and another six months to phase it in. And it sure will require downtime!
For all of the talk of mission critical feature this and enterprise functionality that, in the end, these "real work" loads are handled by the resourcefulness of your people, because no platform is going to even come close to solving all of your problems.
Package X vs. package Y does not make a difference in the big picture. If only. MySQL, PostgreSQL, Oracle, BerkeleyDB, or peach fuzz? The answer is obvious: pick the one your team is most capable and most comfortable with. Got it? Great! You've just solved the easiest problem you're ever going to have.
Bah! Humbug.
Have they fixed the language incompatibilities? (Score:3, Interesting)
Fixing 10 years of criticism, 10 years too late (Score:5, Insightful)
In the ensuing 10 years, they've thoroughly corrupted the minds of young programmers and DBAs by making them think it's okay to sacrifice data integrity for the illusion of speed ("illusion", because mysql chokes when you get into complex data sets or queries; the vaunted speed of mysql only applies when you're working with a data set so simple you could represent it with flat files or xml without any difficulty). That it's okay to work around the shortcomings of a RDBMS in your application code (no, I am not going to implement transactions, referential integrity, or subqueries in my application code. That's just stupid). That you don't need views or sub-selects or triggers or stored procedures. That adding those features actually slows down your RDBMS (well, yeah, if you implement them poorly).
While it's nice to see that they'll finally support most of the features of a proper RDBMS, it's too little too late. Even if they ship tomorrow it'll be years before this new version is ubiquitous (how many ISPs and hosting providers are still running an ancient 3.x version of MySQL?). The best way for them to have "fixed" those 10 years of criticism was never to have allowed the criticism in the first place -- by fully implementing an RDBMS, or at least acknowledging the benefits of the features you don't implement, like foreign keys, rather than spouting out crap about how adding those features will slow things down, and any "smart" programmer can do without them anyway. At least that way they could've avoided looking like hypocrites.
"You don't need transactions. Transactions just slow things down. Look, we have table-level locks. Use those. You can ensure data integrity from your application by using table-level locks. Performance concerns on locking a full table to update a single row? What?" and then, "Would you look at that? Transactions! You can get them if you use this new table type. Of course, if you don't have that new table type and you try to use it, or you do have the new table type but you don't explicitly mark your tables as that new type, you're not going to get transactions. Oh, we won't fail, we'll just silently not open a transaction, and silently not rollback or commit when you ask us to."
"Sub-selects? Sub-selects are slow. Why would you need sub-selects when you can do two queries, pull all of that data back to your application (because you don't need stored procedures either), and mimic the sub-select there?" and then, "Oo! Sub-selects! Pretty!"
etc ...
Re:Fixing 10 years of criticism, 10 years too late (Score:3, Interesting)
The reality of the matter (that you articulated quite eloquently) is that MySQL has never been a true RDBMS due to it's lack of features. The aspect you mentioned of MySQL encouraging poor development habits is one that I hadn't thought to mention, though I deal with it on a daily basis.
Far too often, I find myself assigned to clean up after several developers in another department
Re:Fixing 10 years of criticism, 10 years too late (Score:5, Insightful)
It's not that simple in the real world. Think about things like concurrency. If you have 200 clients running your app at the same time and 10 of them are trying to update a complex set of related tables, how do they avoid stepping on each others toes? Are you going to have your client apps communicate with each other and coordinate the inserts? Or just lock all the tables and kill performance? How do you ensure that everyone who is reading those tables sees a consistent data set?
Or you could let the DB server do it, since it knows both the data model and the state of all the clients. Things like transactions keep clients from seeing unfinished inserts (and PostgreSQL and Oracle have MVCC to make this very efficient).
Sure, for websites and blogs it doesn't really make a difference. Every once in a while you'll see some odd data appearing on the page but if you refresh it will be gone. MySQL has historically been very good at running simple things like this.
Anything more important than that needs real data integrity at the database level. Application level checks can't *guarantee* the state of the database when more than 1 user is connected, no matter how careful they are.
Question (Score:3, Interesting)
My prediction (Score:3, Informative)
OK, how about java stored procedures? (Score:3, Interesting)
LOL (Score:3, Insightful)
i'm confused.... (Score:5, Informative)
Comment removed (Score:5, Insightful)
Re:Opinions... (Score:3, Informative)
Gaaaaah! The tragedy of your story is that Postgres quite likely would have worked well for the project your describe. MSSQL still uses row locking, so Postgresql > MSSQL for loads with high insert/transaction rates and many concurrent queries.
MySQL is great for simple stuff but absolutely bogs down when you throw anything complex at it. Postgr
But does it support WITH RECURSIVE? (Score:3, Insightful)
too late (Score:3, Insightful)
Since I'm using Hibernate for most new development, there's nothing stopping me from looking at the more advanced RDBMSs out there. Given how MySQL told us we were wimps for wanting things such as triggers and FKs, I don't really trust them to keep understanding what I need as a developer.
How about fixing the ACID compliance? (Score:4, Interesting)
(Was the corruption due to a disk lying about cache flush/disable? Easy, test the disk. If it doesn't lie, then MySQL was the culprit.)
Re:Beta? (Score:5, Informative)
Uhh, just look a little deeper.
Re:Replication? Clustering? (Score:5, Informative)
http://dev.mysql.com/doc/mysql/en/replication.html [mysql.com]
http://dev.mysql.com/doc/mysql/en/mysql-cluster-ov erview.html [mysql.com]
Re:Replication? Clustering? (Score:5, Informative)
The number of companies who NEED clustering is much, much smaller than the number who need triggers, views, etc. No database professional would touch a product that doesn't support those with a ten foot pole, which is why people who actually know databases (as opposed to your average 50-pages-of-PHP newbie) have disdained MySQL for so long.
Here's a step-stool (Score:3, Insightful)
Re:Here's a step-stool (Score:3, Informative)
I guess the .org and .info dns registries aren't mainstream then. They're running postgresql to handle those registries and they seem to keep up without problems.
Re:Replication? Clustering? (Score:4, Funny)
Yahoo surely employs "database professionals"?
Yeah, you got it bud. I'm an HTML programmer, and I see this all the time from elietist guys that say HTML isn't a programming language.
Yahoo employs lots of programmers. They use HTML. So surely HTML is a programming language too! Up yours elietist guys!
Re:What about foreign keys? (Score:5, Informative)
Re:What about foreign keys? (Score:5, Insightful)
The same way that MySQL has the constraints feature on columns. But it also isn't implemented correctly. If you insert out-of-bounds data, MySQL silently changes it to a number that it likes. Features implemented half-assed like that aren't really good features.
If they implement views, triggers, and stored procedures in the same crappy way, MySQL is still going to be a crappy DBMS. It will have lots of broken features which will still make it an unsafe place to store data that you care about.
As far as a reference for just some of the problems with their foreign key implementation, and as pointed out elsewhere in the thread, and found here...: http://sql-info.de/mysql/referential-integrity.htm l%233_5 [sql-info.de]
3. Foreign Keys and Referential Integrity Foreign keys are an essential part of any relational database. In MySQL's foreign key support has been added on through the InnoDB extension and is continually being improved. However some aspects of the foreign key implementation, especially in combination with other areas of functionality, may cause unexpected problems.
3.1. ALTER TABLE ... SET NOT NULL
If a NOT NULL constraint is applied to a column, MySQL will set any rows containing NULL in that column to 0 (in integer or numeric columns) or '' ( empty string, in character columns). No warning is given.
In certain circumstances - particularly if the column contains character data - this may be quite practical, saving you an entire UPDATE tbl SET col = '' WHERE col IS NULL.
But - imagine the column is an integer foreign key. And the column it references does not contain a zero. Hmmm...
mysql> CREATE TABLE exmpl5 (
id INT NOT NULL,
val TEXT,
UNIQUE (id) ) TYPE=InnoDB;
Query OK, 0 rows affected (0.07 sec)
mysql> CREATE TABLE exmpl6 (
id INT,
blah TEXT,
INDEX(id),
CONSTRAINT id_fkey FOREIGN KEY (id) REFERENCES exmpl5(id) ON DELETE NO ACTION ) TYPE=InnoDB;
Query OK, 0 rows affected (0.04 sec)
INSERT INTO exmpl5 VALUES(1, 'test');
INSERT INTO exmpl6 VALUES(1, 'foo');
INSERT INTO exmpl6 VALUES(NULL, 'bar');
INSERT INTO exmpl6 VALUES(0, 'oops'); ERROR 1216: Cannot add a child row: a foreign key constraint fails
SELECT * FROM exmpl6;
| id | blah |
| 1 | foo |
| NULL | bar |
2 rows in set (0.00 sec)
So far so good - this proves the foreign key constraint is being taken seriously. Now the fun starts:
ALTER TABLE exmpl6 CHANGE id id INT NOT NULL
Query OK, 2 rows affected (0.12 sec)
Records: 2 Duplicates: 0 Warnings: 1
INSERT INTO exmpl6 VALUES(NULL, 'bar');
ERROR 1048: Column 'id' cannot be null
INSERT INTO exmpl6 VALUES(0, 'oops');
ERROR 1216: Cannot add a child row: a foreign key constraint fails
This is perfectly normal behaviour for a well-adjusted database. Now let's have another look at what the table contains:
select * from exmpl6;
| id | blah |
| 1 | foo |
| 0 | bar |
2 rows in set (0.00 sec)
I don't recall successfully inserting the zero in that second row - do you? Perhaps I secretly inserted a row into exmpl5 with 'id' set to 0?
SELECT * FROM exmpl6 e6 LEFT JOIN exmpl5 e5 ON e5.id=e6.id;
| id | blah | id | val |
| 1 | foo | 1 | test |
| 0 | bar | NULL | NULL |
Err, no. All I can think of is that the foreign key was arrested as a potential terrorist suspect while I was seeing what other databases did given the same set of queries.
(Note: MySQL 4.1.7 raises a warning after the ALTER TABLE statement above with the cryptic message Data truncated for column 'id' at row 2.)