'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!
What about foreign keys? (Score:2, Interesting)
Other DBs (Score:4, Interesting)
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.
values (Score:2, Interesting)
Why would I switch from PostgreSQL now?
Re:being a paying customer... (Score:2, Interesting)
Given the widespread use of MySQL to run some very complex systems, I rather suspect that you, like most anti-MySQL trolls, have no idea of what the "typically skilled MySQL user" actually does. Yes, there are lots of people who pick it up because it's free, easy to use, and widely known who have no business doing any kind of DB work. There are also those of us -- a lot more than you think -- who make our living at it and know exactly what we're doing.
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?
Core feature or table type feature? (Score:2, Interesting)
For instance you can't do transactions with MyISAM, but you can with InnoDB. You pick what you need.
I think the question that needs to be asked is where in the mysql engine will these features be added? Into the core? Into the MyISAM tables? In a new table type (i.e. MyISAM2)?
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.
Re:Who's still using mysql? (Score:2, Interesting)
In the early days, it was hard to work around the lack of stored procedures, triggers, and views... I was coming from an Informix background with some Oracle experience... but nobody I worked for wanted to license one of those for web stuff at the time. And now that MySQL is about to add the stuff I used to wish for, I actually don't really need it -- I've long ago gotten over the lack of these features.
So I'm primarily going to use the 5.0 release as an excuse to demand a week or two of feature-freeze for hack cleanup, under the guise of migration testing.
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
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 call those dorks at slashdot and pay them to link to a little pseudo story about mySQL."
Re:What about foreign keys? (Score:1, Interesting)
I'd say this was a little more pertinent [sql-info.de].
Have they fixed the language incompatibilities? (Score:3, Interesting)
Question (Score:3, Interesting)
OK, how about java stored procedures? (Score:3, Interesting)
Re:being a paying customer... (Score:1, Interesting)
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: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 a power outage should make an ACID compliant database corrupt.
Re:Bugfest (Score:2, Interesting)
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:Meanwhile, back in 3.23.x land... (Score:2, Interesting)
Re:being a paying customer... (Score:1, Interesting)
Oracle is slower then hooking up a Tab delimted file as a linked table through an access database. Oracle has never been speedy. Its been about being able to handle the load of millions of transactions a second.
MySQL - I love it! (Score:2, Interesting)
I would love to ditch our one critical MS-SQL server and convert it to MySQL but that one is heavily dependent upon triggers and stored procedures for two databases. Until MySQL 5 is up to snuff we won't even entertain transitioning those two.
That being said, I note that the MySQL Migration Toolkit is very nice. Too bad you can't suck the data from an MS-SQL server yet. But give it time - someone will figure out how to do it.
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 here who create disasters of database-driven crapplications on MySQL without following the most basic tenets of database design (referential integrity, normalization, etc... If I had a dollar for every time I've come across one of these guys' big, honking, 74-column tables, followed by someone asking me "Why are there so many 'dupes' in this table?"...<deep breath>).
For the longest time, I couldn't figure it out. Were they lazy? No, I had personally witnessed their work-ethic -- which was solid -- and they always got their deliverables in on time, spending lots of extra time in the office (there's a reason for that, of course...). Were they incompetent or unskilled or just dumb? No... All three of them always wrote very stable, elegant (albeit copious) application code. Although, with the shitty DBs they created, I guess they had to write a lot of application code -- lots and lots and lots of it -- to just make their stuff work. Anyway...
Eventually, a position in my department opened up, and my one-table friends decided to apply. In my interviews with them, I discovered that before working here (where they're occasionally exposed to Oracle, Sybase, and SQL Server), they had experience with only one database platform. Take a guess what it was. Think hard...
Needless to say, they didn't get the job (although I now have two of them writing application code ONLY... and they're pretty f'ing good, interestingly enough). Obviously, they're an extreme example, and I can't fairly attribute their shortcomings solely to using MySQL. But it certainly didn't help (I mean why bother creating a normalized schema when you can't ensure referential integrity at the DB level anyway, right?). Sure, they could have found a way to learn the skills somehow or they could have been more curious or driven to learn, and maybe they just aren't interested in DB stuff and maybe they shouldn't be being asked to do it, I dunno. But after seeing their resumes, I haven't hired one person -- not a single one -- who doesn't have database experience outside of MySQL. I just can't see a MySQL-only person fitting into a Oracle or Sybase or, heck, SQL Server world (yet, I guess).
Anyway, rambling aside, I think the moral of the story is that using robust tools lends itself to building robust skills, particularly in the realm of RDBMSs. MySQL isn't evil and it isn't a bad little database platform for happy little applications, and I'm sure a ton of now very-skilled DBAs and developers might have gotten started using it. But a true RDBMS it has not been, for ten freakin' years. And more importantly, MySQL skills do not real DBAs make.
Anyway, if it is in fact now a competitive product, I guess my collegues and I will have to stop jokingly calling it "Access for Programmers". But if it stacks up and (FINALLY) does what a lot of us need a DB to do, with the speed and stability it's already known for, I'll throw it behind one of my apps tomorrow. I've got my fingers crossed, but after 10 years of persistent let-downs, don't blame me for not holding my breath.
Re:being a paying customer... (Score:2, Interesting)
I agree with you, the process is a serial one, but when optimizing anything, you spend the time where you get the biggest bang for your buck. Right now, the first big bottleneck is going to be the wire. You can control this to some degree buy buying a really big pipe, but thats it. You have no control over if your viewer is on a t3 or a 14.4 modem. The next big gain would probrably come from some form of caching system, or accelerator. After that, your biggest performance gain would probrably come from cleaning up the code size of whats being returned to the client( which sadly, most people still dont seem to do
The type of queries being done on most websites, just arent that intensive. Normally its straight out lookups, maybe a few cross table joins, etc. Very little analysis type operations happen in most sites, although granted, I imagine there are exceptions. We are talking minimal fractions of a second here.
I guess my argument is, with all the other problems/bottlenecks, etc in the loop... the database backend is really quite far down the list. Im not saying there is no advantage to optimizing the database... im just saying its minimal compared to everything else. Granted, this argument applies to *most* sites. There are exceptions again... the googles and amazons of the world. Even then, its not so much the performance cost of the queries that comes into question, is purely site traffic volumes. With that massive amount of traffic, you need a highly scalable system at every level. But, most sites, arent google!
As an asside, I have a similar background to you. In the mid 90's I worked for a company that made a product called Tango, which was a Cold Fusion-esque, web application server. It was slow... for the most part, the databases of the day... well... they were slow... Everything was basically just slow. Yet, in the end, where did we get our biggest bang to the buck for optimization? By minimizing the size of the HTML and images returned. By a huge margin. All the optimization in the world on the back and, and frankly, the end users still most likely wouldnt have noticed because... well, they still spent just as long waiting for the crap to download in the first place. This isnt in regards to small sites either... im talking fairly major Canadian online banks (mBanx) and such.
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:well (Score:2, Interesting)
Joe sixpack isn't going to use Oracle 9i for his blog, and your bank will never use MySQL for financial transactions.
If anything MySQL should be cutting 'junk' so that it leans more on the SQLLite side of things instead of the PostGreSql side.
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 article I'm telling you about was written (1996 or so) a grand total of exactly 17 bugs was found in unit testing.
One member of the team was quoted as saying, "We don't work late. We know that if we work overtime and get tired, we might introduce a mistake. If we introduce a mistake, somebody that we go to meetings with every week will die."
(That's me paraphrasing, obviously, but the "somebody will die" wording is a quote. That's the kind of thing that stays with you, you know?)
When you consider that a huge amount of computer code being written today is used in things like airplane avionics systems, car and truck engines, life-support machines and, yes, space ships, you realize that this whole "we're not perfect, we rely on users to send us bug reports" attitude is laughable in the extreme.
You don't get a bug report when the software that controls the flaps on a 777 fails. You hear about it on the news.
Re:foreign keys? try write-ahead logging (Score:4, Interesting)
Re:foreign keys? try write-ahead logging (Score:3, Interesting)
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.)