Slashdot Mirror
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."
>> 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).
- Sh!t
It has been on slashdot before. Shared Source does not mean what you think it does. In fact shared source is so bad that I have to recommend you quit your job if ever told to look at something under that license.
Shared source licenses cannot touch Samba. It isn't clear if you could touch Samba if you look at code completely unrelated to networking. It is not clear that someone who has ever seen shared source code can ever hack linux. I wouldn't recommend trying, at least not without a lawyer advising you.
The name shared source was chosen to confuse people who know about open source and make you think it is a variation. The whole idea behind them is different.
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.
You shouldn't compare MySQL to M$ Access because Access isn't a client-server database. It's a desktop database for work with other desktop/office applications and the closest comparison is the new Java datbase which comes with OpenOffice 2. MySQL should be compared with M$ SQL Server, though it has less features at present, because both are distributed, client-server architectures.
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).
> 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.
I am no longer wasting my time with slashdot
To be fair, you would have to include MySQL in that list since you cau use the InnoDB tables as well. Also, if you lock all the tables you are using with MyISAM tables you can get isolation... just not so nice for other users.