Table Design

Look-up Tables in SQL

Lookup tables can be a force for good in a relational database. Whereas the 'One True Lookup Table' remains a classic of bad database design, an auxiliary table that holds static data, and is used to lookup values, still has powerful magic. Joe Celko explains....

SQL Server: Natural Key Versus Surrogate Key

When designing a database to support applications you need to consider how you are going to handle primary keys. This article explores natural and surrogate keys, and discusses the pros and cons of each, allowing you to determine what makes the best sense in your environment when you are designing your databases.

Stairway to Database Design

New to the task of designing and creating a database? Joe Celko, who is one of the most widely read of all writers about SQL, explains the basics. As usual, he comes up with the occasional surprise for even the most seasoned database professional. Joe was the winner of the DBMS Magazine Reader's Choice Award four consecutive years. He has taught SQL in the US, UK, the Nordic countries, South America and Africa.
He served 10 years on ANSI/ISO SQL Standards Committee and contributed to the SQL-89 and SQL-92 Standards.

An Introduction to Database Design

An introduction to database design for those people that might not understand what is involved.

Natural vs. Surrogate Keys in SQL Server : Getting the Proper Perspective

This article demonstrates the relative merits of natural and surrogate keys and benchmarks their performance in different scenarios.

Improving Database Design and Performance Using Compression

This article attempts to show a practical scenario on improving DB design and performance through row density and compression in Microsoft SQL Server 2008.

Data Distribution - Part 2

In the second part of this series, Leo Peysakhovich provides a mechanism for tracking real time data changes.

The DIS-Information Principle: A Splitting Headache

You can easily re-factor bad DML code, but if a database design is wrong, you can do little to rescue the problem, even with expert queries. So what constitutes 'wrong RDBMS design? What are these errors that continually crop up? How can you recognise them and fix them? Joe embarks on a new series of articles by identifying a series of bad practices based on the habit of 'splitting' that which shouldn't be split.

Making your database changes backward compatible: Changing a relationship

Let's face it: requirements change. There is usually a lot of churn during the design and initial development stages, but changes can happen to mature applications, too. The key is to introduce those changes with the least amount of effort and risk.