Those are great additions, thanks for the comment.

1) Not properly evaluating the use of natural keys vs synthetic keys, typically resulting in simply applying synthetic (identity) keys to all tables, even when natural keys make more sense.

2) Simply creating “Primary Keys” on tables using the Enterprise Manager GUI, or even scripting and creating Primary Keys, allowing SQL to create the default clustered index. Quite often, primary in data warehouse settings, the clustered index and the primary key should be different. Indeed in some cases the primary key should be on a synthetic key and the clustered index should be on a natural key. 

An example here in my case was a claim transaction table I designed recently, where I created a clustered index on insured id, claim number, transaction date, transaction id. The primary key is simply on transaction id. The transaction id is unique in and of itself, but the way the data is reported on is always in relation to an insured or to a claim, and typically within date ranges.

3) COMPRESSION! Evaluation of compression should be a standard practice for database design now, especially in a data warehouse or reporting type of environment. And this is a big deal, because its not just determining after the fact whether to compress or not to compress, the use of compression can impact your table design.

Again, in a reporting environment, I’m trending more and more to de-normalization and page compression for superior performance. Normalization is still very important in OLTP systems for data integrity, but its much less important now for efficient data storage. As we all know, query performance is generally better for de-normalized data, but in the past the size of the data remained a constraint on de-normalization. It was considered foolish to store duplicate values across rows or to store “decoded values” as opposed to storing tinyint keys that reference de-code tables, etc. But now (in reporting settings) I’m de-normalizing data, flattening it out, and storing real values in the data, using a lot of varchar and even char fields to store the real values of things like “types” and “categories”, etc., etc. And yeah, when you look at the data you see tons of duplication. But guess what, now you throw page compression on it and your 50 gig database shrinks down to 5 gig.

When you write reports against this data its super fast. Very few joins, and now you can put columnstore indexes on it too. In many cases it essentially avoids the need to build cubes. 

Another approach of course is to use a compressed indexed view against normalized data, but I haven’t had much luck with this due to the complexities and requirements of setting up indexed views.