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."
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.
It's great that bugs are fixed, but how about investing more in user education, so that people at least realize that they could have every patch imaginable installed but still be owned by SQL injection, a problem with whoever wrote their webpage or app that interfaces with the SQL server and not the SQL server it self.
MySQL is a lot better about it then MSSQL due to the lack of comments, but disastrous things can still be done with this.
For those that are curious, more info on SQL injection can be found here and here.
Traditionally code complete means all features implemented, alpha testing can begin.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
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.
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.
Fun with Anagarams! LADS HOST, SHALT DOS. HAS DOLTS. AD SLOTHS, HATS SOLD. ASS HO, LTD.
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.
I am no longer wasting my time with slashdot
yes, you have to explicitly say the table should be innodb, which isn't really a major issue.
Actually, yes, it is a major issue. If you ask for an innodb table, and for some reason it's not available (e.g. innodb isn't compiled in, common in hosting environments), then MySQL will go ahead and create a myisam table without warning you. The result? Your foreign keys, which "work just fine" under MySQL, are simply ignored.
I = Isolation
Basically it means that when multiple users are performing operations on the database they should not be able to screw each other up (for example if two users execute an UPDATE on a table, they should not overlap and produce crazy results).
To be technical MySQL does perform the basics of isolation - individual operations are properly isolated from one another by way of ugly full table locking (this is why MySQL [the default MyISAM tables] does so poorly at concurrent inserts and other write operations). However to properly fufill the requirements of isolation you need to actually be able to do entire human operations in isolation. For example executing a series of SELECT/INSERT/UPDATE/DELETE operations (that together do an actual job) knowing that the data won't change right in the middle. These are called transactions, and you'll need to switch to InnoDB tables to get them (InnoDB also has row level locking).
As for other databases that pass that ACID test, well basically all of them do. MySQL is the exception to the rule, owing mainly to the fact that it's more of a fast selecting engine with database like features, instead of a stripped down database built for speed. Off the top of my head SapDB is GPL (and ACID of course), though all of the other big open source databases I can think of are under some other more free licence (Firebird [ACID], Postgre [ACID], SQLite [ACID!])