Reports from the MySQL Users Conference

Eh-Wire writes "OnLamp is reporting on the MySQL Users Conference that is currently underway. Among the highlights are the announcement that the code for MySQL 5.0 is now complete. Axmark and Widenius suggest that squashing bugs is the key behind the success of MySQL. Michael Tiemann from Red Hat and the OSI delivered a keynote on "Defining Open Source". He suggests that Microsoft's "shared source license" has been a complete failure at the design level."

Comments

MySQL's New Slogan

[Anonymous Coward]

"We're catchin' up!"

...Reports from the MySQL Users Conference

[waldoiverson]

i don't think i've ever seen MySQL output a report like this...must have been a weird query.

Squashing Bugs Good?

[mwkaufman]

Who knew? Maybe Microsoft should follow this brilliant business plan.

Objection, redundant

[Tackhead]

> Microsoft's "shared source license" has been a complete failure at the design level.

Due to the rising cost of energy, ink, and/or toner, we urge all authors to reduce their word count wherever possible. For instance, the string ('s "shared source license") in the preceding article is redundant and may be eliminated.

Thank you for your co-operation.
- The Management

From the Article

[DarkHelmet]

"MySQL 5.0 is code complete"

So does this mean they're still doing bugfixes? Or they're doing testing? Or it's going to come out any moment?

Or does it mean that they're no longer implementing new features, which means they're in beta. If that's the case, we knew that much already.

Mysql needs to Improve

[RedElf]

It still has a long way to go, over the last weekend I spent several hours trying to recover data from a backup (mysqldump) because of dataloss due to mysql database corruption on server version 4.0.20.

Sure it seems ok if you want to run a small, fast, dynamic website that doesn't contain any real valueable data.

For serious data needs, in my projects I'll choose Sql-Server over mysql any day of every week. I'm not saying Sql-server is the best choice, but its ahead of mysql when it comes to data integrity.

Re:Mysql needs to Improve

[eakerin]

Data corruption has nothing to do with data integrity.

Data corruption is caused by either a software bug, or hardware problems, and it's a problem with the data as it's layed out in the database's backing file. This type of failure can happen with any RDBMS. I've personally had it happen a few times with MSSQL server. All times were easily repaired with either a re-index of the table, or a partial table restore.

Data integrity is the database ensuring that when you want to have an entry in another table for each row in a table, that you do.

Re:Mysql needs to Improve

[bluGill]

If you are looking for an Oracle replacement try postgresql. Depending on what your needs are it might be better than Oracle, though if you needs are typical of what a business wants Oracle is likely better. Being open source (and more free than MySQL is, as the license is BSD) people do hack it to add weird things to their database.

There are a number of open source databases. MySQL gets the press. That does not mean it is best for your purpose, so you really should examine them all yourself.

Which is best is partially a matter of opinion. Mine is that between sqlite on the low end and postgresql on the high end there isn't much room for more general purpose SQL databases. Of course there are others, I'm not going to list them all because I'll forget at least one if I try.

Re:Mysql needs to Improve

[TexVex]

Data integrity is the database ensuring that when you want to have an entry in another table for each row in a table, that you do.

That's referential integrity. For example, if your database enforces referential integrity between an accounts payable and a payable entities table, if you delete a payable entity then all associated payables records would be cascade-deleted along with it.

And, as an aside, generally if you're going to maintain a record-for-record relationship between two tables, you might as well combine them into a single table.

Data integrity is making sure your data is complete and accurate. The database can assist with this by the enforcement of rules when entering, deleting, and updating information. Extending the above example, you might preserve data integrity by disallowing deletion of a record from the payable entities table when there is a non-zero balance on that account or there has been activity on that account in the past three years.

Re:Mysql needs to Improve

[Michalson]

Your perception of "data integrity" seems very limited, either that or you don't a thing and you're just bullshitting based on your knowledge of "data integrity" in other fields.

In the professional world of databases data integrity is ensured by the ACID compliance of the database. In your post though you only seem to understand the C in ACID, "Consistency". The problem is that out of the box MySQL will often fail the Atomicity and Durability requirements of ACID (and doesn't even attempt I). That means the database or a table can be left in a corrupt, unrecoverable state if interrupted by any number of things (you don't just lose the latest additions, you lose everything, forcing you to restore from a hard backup as grandparent did).

To properly understand this, look at another area where ACID is used. If you are using a disk formatted with FAT32 or ext2 and your computer crashes, you'll end up being forced to run scandisk/e2fsck, which has to go over the entire disk structure looking for errors. In many cases the errors it finds (due to an operation being interrupted leaving the disk in a corrupt state) are not recoverable and if left unchanged will mess things up even more. So you get little chunks of the disk (CHK files when using scandisk) that the system has no idea what to do with (databases are far more interconnected, making one unrecognizable element break the whole thing). On the other hand more modern disk systems (NTFS and ext3) borrow methods from the database world, resulting in a disk system that is ACID compliant. When the system crashes or is rebooted by a power failure, it doesn't spend 20 minutes checking the disk for errors it won't even be able properly fix, it just uses it's Durability feature to "instantly" restore the disk to the last good state (on a standard ext3 formatted 7200rpm drive "instantly" is less then 2 seconds).

The only way to make MySQL ACID compliant (and thus durable enough to store information that's actually important) is to use InnoDB tables instead of MySQL's fast default MyISAM tables. Even then, by InnoDB's own documentation, its particular form of ACID compliance is heavily dependent on how and when the OS writes to disk - you can still end up with unrecoverable InnoDB tables if the system crashes, making InnoDB more a device for its transactional programming capabilities and row level locking then it's long term data integrity features (A, C and I). With real world databases a crash simply means you lose the latest changes, not the whole table (to be redundent, the D in ACID, Durability).

well..

[quark007]

>> He suggests that Microsoft's "shared source license" has been a complete failure at the design level." I agree with what Tiemann says..but to an extent. MySql an JBOSS are now commercial companies who employ team of developers to develop the code much like a proprietory software. The real value in open source is the amount of feedback you get from the developers which in turn improves the quality. Microsoft with its license is trying to just that. And it would succeed..(just like JBoss and MySql have).

MySql 5.1

[514CK3R]

Among the highlights are the announcement that the code for MySQL 5.0 is now complete.

So that means we should expect 5.1 to come out next week as planned?

People give MySQL too much crap...

[Anonymous Coward]

Really, it sort of annoys me. We use MySQL in a live, production environment. We have tables with close to five billion rows in them. MySQL has only given us a problem once. A table was mysteriously corrupted about two years ago. The fix? I opened up a HEX editor and repaired the damage. Restarted MySQL, ran some checks with the included tools, and we were all done. Quicker than pulling tapes, let me tell you.

I am really tired of all the hate around here. Every other comment is "If you're serious you will use Postgres because it has feature x, y, and z which make it a better product and you will suffer the consequences if you use MySQL because it's a bad thing for bad people because they don't like penguins and hot grits and bacon shit!"

Actually, it's not that bad... but it's damn near.

Re:People give MySQL too much crap...

[prog99]

You think hacking a table with a hex editor is good?

Think I'll stick with known good backups , glad I'm not working with your prod environment.

Re:People give MySQL too much crap...

[vadim_t]

Well, it might just be me, but I definitely don't look forward to hex editing databases when the thing goes down and the whole company grinds to a halt.

Now, I will readily say that mySQL has its uses. If you're simply aiming to logging data it works well. IIRC, that's what it was designed for in the beginning.

But it's still quite far from being a good database. Doing crap like silently ignoring things it doesn't like is one of the things that makes sure I'll never use it for anything important.

Re:People give MySQL too much crap...

[Anonymous Coward]

When the number of items on the "gotchas" list for MySQL (http://sql-info.de/mysql/gotchas.html) is less than or equal to the same list for PostgreSQL (http://sql-info.de/postgresql/postgres-gotchas.ht ml) I'll consider using MySQL.

Re:People give MySQL too much crap...

[snorklewacker]

Dude, MySQL doesn't support foreign keys. At all. Though it's good at ignoring them. It doesn't even have VIEWS, mmkay?

There's reasons for the hate, and a lot of it has to do with MySQL AB flogging their mediocre system as the sine qua non of OSS databases, to the point of openly disparaging things like transactions at the time when MySQL didn't support those.

And you thought using a hex editor was acceptable. Wow.

Re:People give MySQL too much crap...

[snorklewacker]

> Most of the gotchas are non-existant when you run MySQL with a brain larger than that of a legume in your head as well.

This is the same tired old argument old-style MacOS zealots always pulled when called on the lack of memory protection: "properly written apps don't crash".

The whole fucking PURPOSE of integrity constraints is to protect your data from stupid mistakes. Databases are designed with improperly written apps in mind. That's why the database manages the data, and the apps don't.

Yes, if a schema is designed by morons, then you don't have much recourse. If a database ENGINE is designed by morons, then everyone downstream is screwed.

currently underway, eh?

[donutz]

"OnLamp is reporting on the MySQL Users Conference that is currently underway."

But the conference website says it finished yesterday...

God likes Oracle!

[EvilStein]

The weather here has been *beautiful* for a while. Today, during the MySQL Users Conference right down the street, we basically get the following:

SPECIAL WEATHER STATEMENT
NATIONAL WEATHER SERVICE SAN FRANCISCO CA
344 PM PDT FRI APR 22 2005

CAZ005>008-065-075-230000-
-SANTA CLARA COUNTY-
344 PM PDT FRI APR 22 2005

STRONG THUNDERSTORMS HAVE DEVELOPED OVER THE EAST BAY THIS
AFTERNOON.. EXPECT
STRONG GUSTY WINDS TO 40 MPH...FREQUENT LIGHTNING AND SMALL HAIL WITH THESE STORMS.

---

I'm telling you, the almighty one himself has made his database choice, and it ain't MySQL!