Slashdot Mirror

← Back to Stories (view on slashdot.org)

'Most Important Ever' MySQL Reaches Beta

Posted by CmdrTaco on from the they-took-my-precious-krow dept.

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!

12 of 632 comments (clear)

  1. Other DBs by drivinghighway61 · · Score: 4, Interesting

    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.

  2. Who's still using mysql? by grahamsz · · Score: 3, Interesting

    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.

  3. At what cost? by Jhan · · Score: 3, Interesting

    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.

  4. Firebird more popular than Postgresql? by russx2 · · Score: 3, Interesting

    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?

  5. The biggest problem is not technical by scorp1us · · Score: 5, Interesting

    ...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.
  6. This isn't just "customer base changed" by jbellis · · Score: 4, Interesting
    I guess you don't know the history here like the grandparent does. MySQL really promulgated a lot of disinformation.

    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:

    There are so many problems with FOREIGN KEYs that we don't know where to start:

    • Foreign keys make life very complicated, because the foreign key definitions must be stored in a database and implementing them would destroy the whole ``nice approach'' of using files that can be moved, copied and removed.
    • The speed impact is terrible for INSERT and UPDATE statements, and in this case almost all FOREIGN KEY checks are useless because you usually insert records in the right tables in the right order, anyway.
    • There is also a need to hold locks on many more tables when updating one table, because the side effects can cascade through the entire database. It's MUCH faster to delete records from one table first and subsequently delete them from the other tables.
    • You can no longer restore a table by doing a full delete from the table and then restoring all records (from a new source or from a backup).
    • If you have foreign keys you can't dump and restore tables unless you do so in a very specific order.
    • It's very easy to do ``allowed'' circular definitions that make the tables impossible to recreate each table with a single create statement, even if the definition works and is usable.

    The only nice aspect of FOREIGN KEY is that it gives ODBC and some other client programs the ability to see how a table is connected and to use this to show connection diagrams and to help in building applicatons.

  7. Re:being a paying customer... by Anonymous Coward · · Score: 5, Interesting

    *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... ;-)

  8. Re:Fixing 10 years of criticism, 10 years too late by reverendslappy · · Score: 3, Interesting

    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.

  9. Re:being a paying customer... by LurkerXXX · · Score: 4, Interesting
    You've never had data corruption THAT YOU KNOW OF. The problem with it is that MySQL rarely throws an error, so the bad data going in goes in silently.

    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.

  10. Re:foreign keys? try write-ahead logging by Unordained · · Score: 3, Interesting

    ... 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?)

  11. Re:foreign keys? try write-ahead logging by Unordained · · Score: 3, Interesting

    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?

  12. How about fixing the ACID compliance? by Daniel+Phillips · · Score: 3, Interesting

    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?