design

Validation

• Use validation only to verify external input, not to catch bugs. In other words, if you're not saving input coming from a user, saving has to work even without validation.

Database

• Never denormalize except for performance reasons; even then make sure that denormalization will actually improve performance.

• Do not confuse denormalization with fixing design mistakes. For example, let's say you have two tables:

  CREATE TABLE political_offices ( id INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255), description VARCHAR(255) ); CREATE TABLE elections ( id INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY, office_id INT(11), date DATETIME );

  If every time you want to print a list of elections with names like 'Company president 2011' or 'Mayor 2008' you find yourself doing the following, your elections table is badly designed:

  SELECT CONCAT(po.name, ' ', YEAR(e.date)) FROM elections AS e INNER JOIN political_offices AS po ON (e.office_id = po.id) WHERE 1=1

  Better design for the elections table would be:

  CREATE TABLE elections ( id INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY, office_id INT(11), name VARCHAR(255), date DATETIME )

  Adding a name column to the elections table is simply adding a missing column, not denormalization.