WordPress 3.0.1 ute

Så kör jag bloggen på nya WordPress 3.0.1! Den nya version tre känns vid första anblick inte speciellt annorlunda från tidigare versioner, dock känns det dagligen som man hittar någon ny liten finess.

En av de mer välkomna nyheterna är den anpassningsbara menyn. Detta öppnar för nya möjligheter att utveckla mallar med special-menyer för olika ändamål.

PHP Serialize vs Database normalization

I’ve recently started developing plugins for WordPress in PHP. Being an old school Perl programmer PHP comes very easy and MySQL is still same old MySQL. PHP don’t have many advantages over Perl in general except one very good one: simplicity. I have always tried to write simple code, not simple in the sense that it doesn’t accomplish complex tasks rather in the sense that while being a huge and complex system it is still built with easy to understand blocks of code. With that being said, there are a few shortcuts I rather not take.

The reason I write this is that in all the PHP applications and PHP documentation I’ve come across regarding serialize() nobody ever mentions database normalization.

PHP Serialize

I found the serialize() function in PHP quite useful, it takes a datastructure and creates a string representation of that structure. This string can later be use with unserialize() to return it to the old structure. An example:

$fruits = array (
"fruits"  => array("a" => "orange", "b" => "banana"),
"numbers" => array(1, 2, 3),

echo print_r($fruits);

The above code creates an array and prints the result. The output of the above will be:

    [fruits] => Array
            [a] => orange
            [b] => banana

    [numbers] => Array
            [0] => 1
            [1] => 2
            [2] => 3

Now if you use serialize on this object the following would happen:

$fruits = serialize($fruits);

echo print_r($fruits);



A long line of strange numbers, just what the programmer wanted! This data is perfect for transfering or saving the state of a data structure for later use. Calling unserialize() on the above string would return it to the same array that we first had.

Database Design

Most applications use a relational database for storing information. A relational database stores all data in tables of rows and columns (or relations of tuples and attributes if you use the original non-SQL names). To make a database work efficiently the design of those tables, rows and columns are pivotal. Any student of database design have probably been forced to read all of the different levels of database normalization. The normalization process, invented by Edgar F. Codd, involves searching for inefficient database design and correcting it.

The very first rule of database normalization called the first normal form (1NF) stipulates that “the table is a faithful representation of a relation and that it is free of repeating groups.” [wikipedia]. This means that there should be no duplicate rows and no column should contain multiple values.

Serialization meets 1NF

What happens if you insert the above serialized data into a column of a row in a database? Well put shortly you get a stored datastructure that can be easily accessed by your application by calling it with the keys for that particular row. The table would probably look something like this:

key value
1 1a:2:{s:6:”fruits”;a:2:{s:1:”a”;s:6:”orange”;s:1:”b”;s:6:”banana”;}s:7:”numbers”;a:3:{i:0;i:1;i:1;i:2;i:2;i:3;}}1Array
2 1a:2:{s:6:”fruits”;a:2:{s:1:”a”;s:6:”apples”;s:1:”b”;s:6:”banana”;}s:7:”numbers”;a:3:{i:0;i:1;i:1;i:2;i:2;i:3;}}1Array

As long as you will never ever search for anything inside the value field this is all good and well (but still goes against my better teachings of database normalization). Take for example the problem of locating all stuctures containing apples or even worse something as simple as ordering the rows by fruit! The structure makes such “simple” tasks very hard.

The use of serialization to encode values into the database might be very tempting. It makes saving complex structures easy without having to worry about database design. Saving data in serialized form is however very inefficient from a database design standpoint, the data should have been stored in separate tables reflecting their internal structure.

As I said in the beginning simplicity is the highest virtue of programming for me, serialize is a simple neat solution for a small problem. What should be remembered though is that serialize is not a swizz army knife that should be used for all the database storage. If you ever think that you will need to search through or handle the information stored, do youself a favour and make it a proper table from the start. In the long run making those tables will be easier than later having to convert all those structures and complex code handling them.

CSS layout made easy

While it hurts my nitpicking handcodeing image to admit it, some frameworks are to good to ignore. One of them I found recently in Google BlueprintCSS. It’s a very flexible framework and with a license “you cannot refuse”.

I”ve used to code all CSS and HTML by hand (still!) and it is getting pretty tiresome to stumble over the same defects in every design I make. To pressed for time I’ve never developed a framework of my own, rather just copy and pasted bits and pieces from my old code that I knew was working.

There are many other CSS frameworks out there but somehow I fell for Google Blueprint though I have far from done an extensive testing on them. If anyone have found any other framework very good and flexible please post a comment, I’d love to hear it.