Slashdot Mirror
'Most Important Ever' MySQL Reaches Beta
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!
TFA doesn't mention anything about foreign key relationships, but it sounds more than a little weird to implement views, triggers and stored procs before FKs. Anyone know?
This is certainly good news for MySQL, but many open-source advocates forget about other open-source DBs like PostgreSQL, which has had these features for a while. But competition is always good, and it's good to see MySQL stepping up its value.
Seems like sqlite or hsqldb make more sense on the low end and as always there are better (though often more expensive) options on the high end.
It's great for prototyping things, but i just can't imagine running something critical on it.
So it doesn't randomly pick a value when the user tries to insert something invalid???
Why would I switch from PostgreSQL now?
As someone who has been developing enterprise apps with MySQL for a while now, I'll answer this, even though I'm 99.44% sure you're trolling: what we've always done, so far, is put all the triggers in the application layer. Now we can make "real" triggers in the DB layer, but guess what? The logic is exactly the same.
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.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
So now MySQL is a "real DBE". Does that mean this new version is no longer 5-10 times faster than the "real DBE" (Informix) that we abandoned for the one reason that MySQL has extreme performance?
I do hope all these new features are either off by default or easily turned off.
I choose to remain celibate, like my father and his father before him.
From the article:
"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?
Some of the people making comments haven't really hit on one of interesting things in MySQL, the ability to use different table types.
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)?
this is great news for the open source database community, but i can't help but wonder if we shouldn't be more interested in PostGreSql instead, given it's more open license terms
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.
Business Voyeur
...but legal. The community seems to have over-looked the license change from the 3.xx days. I should know. I had software that was permissible to be run on gratis-MySQL, but as of 4.0, the license changed. I now use PostgresSQL which I throughly advocate, not just because of the license, but because of the feature set and the anal developers.
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
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
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 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."
$5 / month hosted VPS on linux = awesome!
One of the things that's a real problem for me with MySQL is the places where MySQL doesn't follow the SQL language standard. This means that MySQL scripts typically only run against MySQL. This is probably just ignorance on my part - perhaps they fixed this long ago, and people are just coding to the old standard - but does anybody know anything about this? I wasn't able to find anything about it in the press release.
What about bi-directional replication? I know, t'ain't easy, but is it easier now?
Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
This can be done in Oracle and I believe Postgres. Not only do they perform better than native stored procedure languages, they potentially allow you to take code that benefits from being in the database tier and make it portable.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
So I guess you've never heard of a wrapper. When a call is missing something that you need, you put a wrapper around it and do all calls through the wrapper. Guess what, no repeated code.
Here's what the MySQL docs (source: http://web.archive.org/web/20000619203550/http://w eb.mysql.com/Manual_chapter/manual_Compatibility.h tml) used to say about foreign keys, for instance:
Why does this stuff always get propagated? There are several table types in MySQL. If you want ACID, use InnoDB and not the default MyISAM:
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.
-- The world is watching America, and America is watching TV.
I agree. Especially with something as critical as database software, I can tell ya' that if the final version comes out, say, this summer, that I won't even consider looking at MYSQL for another few years.
I don't respond to AC's.
*shakes head*
;-)
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...
If something isn't broke, why break it by upgrading? MySQL is constantly changing little details about how their DB works... take a look at a random page in their documentation and you will see notes like "in 4.x.x we changed this" all over the place. 5.0 sounds like it will be a very feature rich database (Yay, triggers!) but it will be a probably be a pain to upgrade. Little quirks that I've relied upon will no longer work that way. Maybe after this release, things will start to stabilize. Doubtful though.
Apples to rocks my friend.
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.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
We just upgraded to MySQL 4.1.1 - suits our needs. Fast, cheap and reliable.
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.
Amen! I've posted my criticisms of MySQL here before, only to be taken to task by the unwashed masses of MySQL "admins".
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.
I agree to some degree with what you are saying, *but*, I hold true to my origonal argument. To the typical end user, all the optimisations you make on the back end will be pretty much un-noticed. Unless you are returning obscenely large or complex data sets, the time spent on the database is overwhelmingly trivial compared to the latency from the network.
:( ). Lastly, you probrably get the next biggest bang optimizing your server side code to work quicker. Then, the databases performance comes into question
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.
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.
Do you know the story of the software that runs the launch of the space shuttle? I read an article about it in Infoworld years ago. I don't guess there's a copy on line.
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.
... or Firebird with safe-write enabled. There's no appreciable start-up cost even if your db server lost power in the middle of a large transaction. It will reclaim "garbage" space during normal activity as it discovers areas that aren't in use because their transaction got rolled back by the power failure. Handy. (Firebird and PostgreSQL are extremely similar in terms of transactional capabilities; the big difference was SWEEP vs. VACUUM, which apparently Pg took care of in 8.0?)
Doesn't "Vacuum" now run without having to take the database offline? As I understand it, that was what was keeping Pg from being truly 24x7. "Sweep" in firebird runs as a background process and -might- slow down the server while it's running, but doesn't prevent anything from happening. I thought that's what Pg had switched to?
Without proper ACID compliance, everything else is decoration. The recent failure of one of the Wikipedia MySQL servers to start up again after a power failure proves beyond a reasonable doubt that MySQL is not ACID compliant.
(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.)
Have you got your LWN subscription yet?