The latest from the MySQL community

Back in 2000 I began writing for swynk.com in hopes of learning more about SQL Server and beginning to make a name for myself in the SQL Server community. That was a little over seven years ago. As SQLServerCentral.com came online, I transitioned to it, writing articles and contributing heavily in the forums. Opportunities abounded from this effort, with the chance to write an eBook, the chance to become a regular columnist for SQL Server Standard Magazine, and later a chance to become a co-author of an in-print book, …

I’ve had one session accepted at the 2008 MySQL Conference & Expo (which is a good thing since I only submitted one session for nomination).

This year’s session is titled How to be Normal, a Guide for Developers. I decided to return to my old Normalization talk, but lean more towards the practical than the theoretical this year and work on common scenarios faced by developers rather than walk a person through the normal forms like I have previously done.

Here’s the abstract I’ll be sending in to replace the ugly one I submitted with:

At some point in every software project involving a database it becomes necessary for the developers who created (or inherited) the project to step back and take a look at their database. Many projects have a database schema that has evolved over time, with columns added here and tables added …

I've been getting pinged about query prioritization because of a comment I made elsewhere so I might as well explain the idea :)

If you have a given number of processors, lets say 32, you may want to reserve a set number across a spectrum of performance. For instance let us take a fuzzy definition of:
Slow
Fast
Unknown

You could then map half your processors to Fast queries, and then split your Slow and Unknown queries across your other processors. That way you could always know that you have enough CPU to handle Fast queries (or you could give hints that certain queries matching a pattern should always be fast).

With MySQL you never have costs which are exact before the query is optimized, namely because the optimizer recomputes the execution path for each query. This means you do not have stale data being used for execution, but it means also that the query is always being …

Sometimes it would be handy if you know how to re-package a MySQL rpm. You might wonder how this will benefit your system. Well, for starters, consider if you have custom-built scripts that needs to be in all the database servers. Also, consider if you have a standard way of organizing your database structure such as separating your logs with your data files.

A re-packaged MySQL rpm would come very handy in these situation. I've used this a lot in my companies and if you don't have a Red Hat OS, then consider writing a script to handle your automated MySQL installation.

As my former boss will attest, I have a reputation for being a bit of a data quality zealot. The storage of data that is unfit for use leads to many problems, but I suppose that’s another subject for another day.

It’s tough enough to manage data quality problems introduced by source code errors, system failures, and requirements misunderstandings…But a default installation of MySQL introduces a new and exciting way to give us data quality evangelists fits: It allows unfit data to be inserted in the database. That’s the bad news. The good news is that by making a simple configuration change you can prevent this, and override the setting when you don’t care.

In a default MySQL installation, the value of the SQL_MODE system variable is set to ‘’. This allows you to force inserts and updates that may violate the intended design of the table. This point is more philosophical than technical, but in a mission …

As my former boss will attest, I have a reputation for being a bit of a data quality zealot. The storage of data that is unfit for use leads to many problems, but I suppose that’s another subject for another day.

It’s tough enough to manage data quality problems introduced by source code errors, system failures, and requirements misunderstandings…But a default installation of MySQL introduces a new and exciting way to give us data quality evangelists fits: It allows unfit data to be inserted in the database. That’s the bad news. The good news is that by making a simple configuration change you can prevent this, and override the setting when you don’t care.

In a default MySQL installation, the value of the SQL_MODE system variable is set to ‘’. This allows you to force inserts and updates that may violate the intended design of the table. This point is more philosophical than technical, but in a mission …

You can read the full announcement in the news post at phorum.org.

Summary:

When we officially started on 5.2 in March of 2006, we had several goals. I think we achieved most of those. We also accomplished some unplanned things. Our hackathon (me and maurice slept about 8 hours in 4 days I think) at MySQL Conference 2007 helped a lot. Remember, you can help us get there again by donating to our fund.

Some highlitghts:

New Template
New API layers and more hooks
Better MySQL support
Improved bundled modules
New announcement system
New Search, inside and out

In addition to all this, there are things like more caching options, the new hybrid read view, the new feed options (the feed code was rewritten from scratch) and …

A

The nice folks over in Luxembourg just posted the schedule for their Linuxdays 2008 conference.
I`ll be talking about MySQL High Availability

I was at LinuxDays.lu already 2 years ago and I remember it as a nice an cosy conf with an interesting combo of tutorials and conference talks. If you are in the neigborhood its worth the time.

Oh .. and you can also see Matt in action again :)