Database Design

An INT primary key .... yet not an Identity?

Jeff Smith — Thu, 21 Feb 2008 17:08:46 GMT

Ah, this is not an anti-identity rant, don't worry!

Though, in a round-a-bout sort of way, it is yet another argument against always blindly using them -- but not in the way you might expect.

There is a simple rule I'd like to propose, let me know what you think:

"If your client code, SQL code, or configuration files reference the primary key column of a table to determine any application logic, that primary key column should not be an identity."

Now, I am not saying that primary key column can't be a meaningless integer. I am just saying it should not be an auto-generated meaningless integer.

Working with an inherited web application (in "classic" ASP .... yuck), there were lots of tables like this:

groupID, groupName
1, Administrator
2, User
3, Finance User
5, Account Manager
8, ReadOnly

and there was lots of code written like this:

if groupID = 1 then show delete button
if groupID =3 or groupID=5 and groupID != 8 then show the create new project button

... repeated everywhere, throughout the application and in the SQL code.   Yet, the groupID column was an identity.   I discussed a similar issue here, but this is a slightly different approach.   In this case, let us assume that we really want to -- or need to -- embed that "groupID" value everywhere in our code. And we want that table to have an integer primary key to keep things short and simple and precise in our database code. That's all fine, it happens, and it certainly is common.

But why does that groupID need to be an identity?

For static, non-changing system tables, why assign an identity primary key? Why not just make it an integer? And once a year or so when someone adds and entry to this table (usually manually, behind the scenes with an INSERT command or opening the table directly) what is so bad about having them manually "figure out" the next ID to use and manually insert it?

The database will always have that primary key constraint on the column -- we don't gain any integrity by using an identity. We just gain ... well, what exactly do we gain when the table is static?

The advantage of not using an identity is this: if we wish to confer meaning on these ID values, we have complete control over them. Moving from one system to the next means we can just copy them over and we don't need to worry about setting IDENTITY INSERT ON and things like that.   We don't have to worry about gaps in the sequence or re-seeding the tables. We can guarantee that we have complete control over these values, and they never will be created anywhere unless we explicitly create them.

If we do use an identity, that's great the next "ID" will pop up magically, but what good does that really do for us in this scenario? I understand that when an order is generated, or a customer is added, or for things like that, an IDENTITY is the way to go. But for static tables, I really honestly don't bother with an identity. Just put an INT primary key on there and you are good to go.

The reason I bring this up is as the result of a mini-debate with another developer. If a system table such as "Status" will only ever have 3 values, and we wish to assign each of those values an integer "ID" as a primary key, why bother with an identity? Why not just use a standard, non-auto-generating integer column as the primary key?

Do the pros of an identity in this situation outweigh the cons?

Then again, I am a bit of a control freak, I admit ... But I think that key values in your data tables that your applications and systems rely on are a pretty good thing to have control over.

(Another minor point oft-overlooked: Don't forget about considering the use of tinyint or smallint data types for these columns as well. )

Implementing Table Inheritance with SQL Server

Jeff Smith — Thu, 21 Feb 2008 16:05:35 GMT

I have a new article up at SQLTeam:

Implementing Table Inheritance with Sql Server

It discusses the situation where you have multiple entities that are distinct, yet they have many attributes or relations in common. There is an easy way to simplify your database design and your code if you use the concept of a "base table" for that common data, which is very similar to the concept of Inheritance in Object-Oriented programming.

I recently had to do this for a client that tracks Contributions to their foundation; there is a base set of data that all Contributions have, such as who donated, how they paid, the date a tax letter was sent, etc. But for certain contribution types we need additional information, such as if they bought an Auction Item, sponsored an Event, and so on. Thus, we set up a "base table" of Contributions and sub-tables for the different types, and set up a constraint to ensure that the right subtable is used depending on the type.

It sounds complicated and like it may require fancy triggers or at the very least CHECK constraints, but it is very easy to model in T-SQL -- especially in SQL Server 2005+. The end result is that you have a less redundant database design and much less code to write to maintain that data.

Check it out if it sounds interesting, or helpful, or if none of this makes any sense and you're wondering what the heck I'm talking about.

Interesting Database Modeling Dilemma

Jeff Smith — Mon, 07 Jan 2008 15:52:26 GMT

Let's say you have a database that contains Companies, Products and Stores. Products and Stores are unique to each company -- i.e., they are not "shared" across companies.

create table Companies
(
    CompanyID int identity primary key,
    Name varchar(100)
)

create table Products
(
    ProductID int identity primary key,
    CompanyID int references Companies(CompanyID) not null,
    Name varchar(100)
)

create table Stores
(
    StoreID int identity primary key,
    CompanyID int references Companies(CompanyID) not null,
    Name varchar(100)
)

OK, looks very simple and standard, right? Now, suppose we wish to create a table that lets us relate products to the stores that sell them:

create table StoreProducts
(
    StoreID int references Stores(StoreID),
    ProductID int references Products(ProductID),
    primary key (StoreID, ProductID)
)

All is well and good in the world -- except that we now have a very flawed data model that does not constrain at all against entering potentially meaningless data!

The problem? We can easily relate Stores for company X with products for Company Y. None of our constraints disallow this from happening. Yet, it is a simple data model and this is a simple situation and it was very easy to overlook. If we have any data of that sort in our database, it is effectively garbage and we should not be allowing it.

So, the question is: what is the most effective way to handle this? How we can ensure that only Stores and Products for the same company get related?

This seems to be a case where composite primary keys might be required. Using composite primary keys for the Products and Stores table that includes the CompanyID column as well (making those tables more like "child" tables of Companies), we can obtain our goal like this:

create table Products
(
    CompanyID int references Companies(CompanyID) not null,
    ProductID int identity,
    Name varchar(100),
    primary key (CompanyID, ProductID)
)

create table Stores
(
    CompanyID int references Companies(CompanyID) not null,
    StoreID int identity,
    Name varchar(100),
    primary key (CompanyID, StoreID)
)

create table StoreProducts
(
    CompanyID int,
    StoreID int,
    ProductID int,
    foreign key (CompanyID, StoreID) references Stores (CompanyID, StoreID),
    foreign key (CompanyID, ProductID) references Products (CompanyID, ProductID),
    primary key (CompanyID, StoreID, ProductID)
)

In the above model, we have solved the problem -- only stores and products for the same company can be related. Yet, this doesn't seem very intuitive and doesn't seem ideal.

We could also leave the PK of Stores and Products as the single identity columns and add additional unique constraints to these tables to use in the foreign key constraints, but would the design still be normalized? The CompanyID column in our StoreProducts table would be a redundant attribute that is already stored in other related tables. Storing redundant data as part of a primary key certainly doesn't violate the principle of normalization since that is how we relate two tables, but storing redundant non-PK attributes certainly seems to. Then again, the unique constraint would simply be an alternate primary key so I suppose that would be fine.

The "unique constraint" version of the model looks like this:

create table Products
(
    ProductID int identity primary key,
    CompanyID int references Companies(CompanyID) not null,
    Name varchar(100),
    constraint Products_altpk unique (CompanyID, ProductID)
)

create table Stores
(
    StoreID int identity primary key,
    CompanyID int references Companies(CompanyID) not null,
    Name varchar(100),
    constraint stores_altpk unique (CompanyID, StoreID)
)

create table StoreProducts
(
    CompanyID int,
    StoreID int,
    ProductID int,
    foreign key (StoreID, CompanyID) references Stores (StoreID, CompanyID),
    foreign key (ProductID, CompanyID) references Products (ProductID, CompanyID),
    primary key (StoreID, ProductID)
)

So, be aware of situations like this when designing your data models -- things are not always as simple as they seem. The two techniques shown above will help you to avoid making the modeling error described here and will keep your data accurate and consistent, without the need for triggers or relying on application code to validate data. It seems funny to take a perfectly unique identity and make that part of a primary key or a unique constraint, since it is unique on its own, but as you can see here it is often a very useful technique.

When choosing a unique constraint or composite primary key, I think the main question is this: Do all (or most) of the the tables related to that entity need both columns for other relations and/or constraints? If so, then use a composite primary key, since you will always be relating on both of those columns anyway. However, if it is rare that you would need to relate back to those entities on both columns, then I would go with a unique constraint.

Does anyone have other (better) ideas out there for handling situations like this? This is a great example of how data modeling is truly an art and not a science.

see also:

Working with Date and/or Time values in SQL Server: Don't Format, Don't Convert -- just use DATETIME

Jeff Smith — Wed, 29 Aug 2007 14:04:02 GMT

The Importance of Data Types

Imagine that SQL Server only provided two data types: the MONEY data type to store numeric values, and VARCHAR to store text.

If you are designing a database in this scenario and you need to store or return integer values, which data type -- MONEY or VARCHAR -- would you use?

Suppose I were to argue that MONEY is too complicated, and a waste of space, since all MONEY values always have 4 digits after the decimal which we don't need and it might get confusing. Therefore, we should use VARCHAR, which is much simpler. After all, if we use MONEY, every time we execute a SELECT, our integer data will be returned with 4 decimal places like "45.0000", which is certainly not what we want and doesn’t look like an integer; but if we use VARCHAR we will get "45" which looks much better and is really what we want to see. While eventually we will notice that we cannot add these VARCHAR numbers together, or sort them, or compare them, or do any kind of math with them, we can always temporarily convert those values to MONEY if we need to do these things, right? And as for ensuring that we only store valid numbers in our VARCHAR columns, we can handle that with some complicated CHECK expressions that parses the string to ensure that it stores only valid digits. We also need to make sure that everyone is aware of the rules for the format of integer data in our VARCHAR columns, to avoid problems as well: after all, we may wish to store values like 34934 as "34,942" so that it looks just right when the values are returned and is easier to work with.

Now, if I make this argument to you, what would you say? Would you think it's a good idea?

I think we can all agree that a much better approach would be to use MONEY. Now we can add, sort, compare, do math, and all kinds of things on our values which are stored as numeric data, not text. We can add a quick, simple CHECK constraint to ensure that our MONEY values have nothing stored after the decimal (e.g., CHECK round(value,0) = value), and we simply let our front end format those numbers without any decimal places. In this scenario, it's probably fair to say that no reasonable programmer would argue that VARCHARs are better for working with integers than a true, numeric data type like MONEY.

Manipulate and Return Data -- not Strings

If we agree to use the MONEY data type, wouldn't it make sense to keep those values as MONEY throughout our T-SQL code, and only return MONEY values to the clients? We wouldn't want to try to convert our MONEY values to VARCHAR in our database code just so that things "look good" and we "don't see" that pesky little ".0000" after each value, right? It means nothing to us, it doesn’t affect our data, so we simply store and work with and return MONEY in all of our database code and we don't worry about formatting or how things "look" or the extra decimal places that we aren't using. This keeps our code short, clear, easy to read since we are not converting things back and forth between VARCHAR and MONEY over and over to make things "look good" in one spot but to make them “work correctly” in another.

Along those same lines, suppose we have a MONEY value like this:

1846.4069

... and we need to return that value as an integer. What should we return, a VARCHAR value or a MONEY value? The VARCHAR value of "1846" will look nice, but again: we cannot sort, compare or do anything with it -- it is just a picture of data, not actual data. If we return a MONEY value of 1846.0000, we can and should ignore the decimal portion since it does not affect anything and enjoy the benefit of returning an actual numeric value that both the database and the client can sort, compare, calculate, and so on.

If you don't agree with any of that, stop reading now and let me know in the comments. Otherwise, let's continue on ...

Another Obvious Example

What about if we want to store only values that are decimals, such as .0234 or .963? These values will never have any digits before the decimal, but will always have one to four digits after the decimal (we only need 4 digits of precision). That is, we are storing values from -.9999 to .9999 only. With only MONEY and VARCHAR available, what data type should we use to store and work with these values?

Once again, suppose I argue that VARCHAR is the way to go. After all, if we use MONEY, every value will be preceded by "0.", which is not what we want and again a waste of space. We don't need the integer portion, and having it returned and seeing it everywhere will be confusing. If we use VARCHAR it will always look perfect, and we again can use CHECK constraints that parse the string to ensure we have valid data. Things still don’t sort or compare or calculate, but we can CONVERT back and forth as needed.

Yet once again, I would hope that you will agree that the suggestion to use VARCHAR is not a good one. We should use a numeric data type, and therefore MONEY is the best choice. It handles our data perfectly with the accuracy we need, we can do math, sort, and compare. We know that it will be valid and accurate, and a simple CHECK constraint ensures that we only have values between -.9999 and .9999 as opposed to using string parsing to determine this. And, again, even though in the T-SQL world all of our money values have an integer portion of “0” attached to them, it should make sense that we should not worry about this since our data is accurate and correct, it doesn't affect calculations, and the client can output these decimals without the preceding “0” very easily.

This also affects doing some math on a value like 139.592 to return only the decimal portion; for all of the reasons stated, we should all agree that the value to return is a MONEY value of 0.5920 and not a VARCHAR value of ".5920".

Finally, if we always store and return MONEY for both our integer values and our decimal values, we have another huge benefit: we can do math on both of those values together and get accurate, consistent results. No conversions, no string manipulation or parsing or concatenation, no worrying about how things are formatted or stored or how they look; we can do simple, efficient and accurate math on all of our data with standard mathematical operations and it just works perfectly and intuitively.

Getting to the Point (Finally!)

Are we all agreed on the above? Good. So, then, what’s my point?

Shouldn't we follow the exact same logic and reasoning when storing date and time data?

The exact same scenario happens every day, only programmers are deciding how to store or return dates without times, or times without dates. Yet, very often we see beginners choosing to store their values as VARCHARs and/or return them and manipulate them as VARCHARs, instead of using the easiest, most obvious and appropriate data type: DATETIME.

Working with Date-Only Data

If you need to store just a date, use a DATETIME. Don’t worry about the “extra” time that is stored, just enforce that it is always midnight and it won’t affect anything – just like forcing a decimal to be “.000” and ignoring it! It is the exact same logic. And, by that same token, don’t worry about that time being there and feel you need to convert everything to VARCHAR to make it “look” right. Just use data in the proper type throughout your SQL code, ignore the time portion, and return the DATETIME value – in the correct type – to your clients. Don’t try to “help” them by converting those nice, accurate, and clean DATETIME values to a string to “hide” the time part – just return the value, just as you would not try to “hide” a decimal portion of “.000” in a numeric by converting it to a string.

Luckily, many programmers do indeed use DateTime when all they want to store is dates, but of course many do obsess about “hiding” that time portion. Don’t do it. Leave your data in the proper type, enforce a time of only midnight with a simple check constraint (e.g., CHECK dateAdd(dd,datediff(dd,0,yourdate),0) = yourdate) and now you can compare, sort, do math, and everything else you ever need on those values, and your client can do the same. Just as you would use a MONEY data type to store numeric data, if you had to, as opposed to a VARCHAR. It’s easier, shorter, and more efficient – it just makes sense.

The same concept applies if you have a DATETIME value like "5/6/2007 5:00 PM" and you'd like to return just the date portion: Should you return a VARCHAR or a DATETIME? For all of the reasons stated, it should be clear that you simply return a DATETIME value a midnight -- "5/6/2007 12:00AM" -- knowing that the time portion is now "zero" and even though it is there and we see it, it does not affect any calculations and can easily be excluded when the client presents the data.

To "round" a DATETIME so that the time at midnight is returned:

select dateadd(dd,0, datediff(dd,0, datetimeval)) as date_at_midnight

Working with Time-Only Data

Now, what about storing only a Time? Here’s where people really get confused, but, again, it is exactly the same as storing a value between -.9999 and .9999 in either MONEY or a VARCHAR. We agreed to use MONEY, and simply accept the fact that our integer portion of “0” is always there, but it doesn’t affect anything; we can simply ignore it and let our client worry about not displaying it. Remember, when storing a true decimal value, we had no choice – that zero was always there, whether we displayed it or not, right? Well, DATETIME values have the exact same concept! The decimal portion of a DATETIME is the time component, and even though we just want to store time values, a DATETIME works perfectly for us. We simply ensure that we store a 0 value as the date portion and we ignore it!

For DATETIME data, a date of “0” that doesn’t affect any calculations is “1/1/1900”, just as a time of “0” that doesn’t affect any calculations is “12:00:00 AM”. Thus, “1/1/1900 12:00:00AM” is the equivalent to a decimal value of 0.0 -- adding or subtracting that value to other values will not have any effect.

In fact, take a look at this:

select cast(0.0 as datetime) as ZeroDateTime

ZeroDateTime
-----------------------
1900-01-01 00:00:00.000

(1 row(s) affected)

select getdate() as Now, getdate() + '1/1/1900 12:00:00 AM' as NowPlusZeroDateTime

Now NowPlusZeroDateTime
----------------------- -----------------------
2007-08-30 20:55:48.513 2007-08-30 20:55:48.513

(1 row(s) affected)

Notice that the numeric value of 0.0 is converted nicely to '1/1/1900 12:00:00 AM', and that adding '1/1/1900 12:00:00 AM' to a DATETIME value has no effect.

So, if we want to store only a time, without a date, we just:

Use a DATETIME data type
Ensure that the date value of that time is 0 (that is, "1/1/1900") with a check constraint (e.g., CHECK datediff(dd,0,TransTime) = 0)
Ignore the date in our SQL code even though we might “see it” here and there
Keep our data in the correct data type throughout our code without worrying how it “looks” and trying to “hide” the date part
Return that DATETIME value to our client and let it worry about hiding the “1/1/1900”, just as we let the client worry about hiding the preceding “0.” in a decimal value such as 0.2394.

Once again, let's consider what to do if we have a DATETIME value with such as "6/1/2007 5:00 PM" and we'd like to just return the time portion: Do we return a VARCHAR or a DATETIME? By now, the answer should be clear: we return data in the correct type, DATETIME, and we simply use the "0" date of 1/1/1900 by returning "1/1/1900 5:00 PM" knowing that the date portion will not affect the time value just as a an integer portion of 0 will not affect a decimal value.

To return just the time portion of a DATETIME (i.e., at the base date of 1/1/1900):

select datetimeval - dateadd(dd,0, datediff(dd,0, datetimeval)) as time_at_base_date

Finally, just as in our previous MONEY example, if we exclusively work with dates and times using the correct DATETIME data type throughout our schema and our SQL code, we can simply add values together to combine a date and a time using simple math:

select somedate + sometime as somedatetime

No converting, no string manipulations or parsing, no worrying about AM or PM or time formats or anything. If we keep our data in the correct types, and constraint it properly, everything works as it should – quickly, accurately, and intuitively.

Conclusion

The next time you are working with dates and times, please remember: how would you handle things if you were working with integers and decimals? The same logic and reasoning applies. Be smart, let SQL do the work for you and use the right data types for the job, even if things don't always "look" right. It's not about how good your data looks, it's about how accurate it actually is.

see also:

Composite Primary Keys

Jeff Smith — Thu, 23 Aug 2007 14:07:20 GMT

Ah … primary keys … such a topic! When discussing what columns to define as a primary key in your data models, two large points always tend to surface:

Surrogate Keys versus Natural Keys
Normalization

These can be very complicated and sometimes polarizing things to debate. As I often try to do, I will attempt to approach this topic from a slightly different perspective.

Let's start things off with what I feel is a good interview question:

How would you define what a primary key of a table is?

a.   An auto-generated numeric or GUID column in the table that uniquely identifies each row
b.   A non-nullable column in the table that uniquely identifies each row
c.   None of the above

I suspect that many people will answer (a), and quite a few will answer (b). If you answer (c), though, you are correct! Why? Because a primary key is not a single column, it is a set of columns. Many people who have designed large, complicated systems are simply not aware of this.

I once worked with a consultant who kept claiming that importing data into his system was complicated, because his database used “primary keys”. It was very confusing (yet humorous) trying to discuss things with him because he kept confusing primary keys with identity columns. They are not the same! An identity column may be a type of primary key, but a primary key is not an identity column; it is a set of columns that you define that determine what makes the data in your table unique. It defines your data. It may be an identity column, it may be a varchar column or a datetime column or an integer column, or it may be a combination of multiple columns.

When you define more than one column as your primary key on a table, it is called a composite primary key. And many experienced and otherwise talented database programmers have never used them and may not even be aware of them. Yet, composite primary keys are very important when designing a good, solid data model with integrity.

This will be greatly oversimplifying things, but for this discussion let's categorize the tables in a database into these two types:

Tables that define entities
Tables that relate entities

Tables that define entities are tables that define customers, or sales people, or even sales transactions. The primary key of these tables is not what I am here to discuss. You can use GUID columns, identity columns, long descriptive text columns, or whatever it is you feel comfortable to use as primary keys on tables that define entities. It’s all fine by me, whatever floats your boat as they say. There are lots of discussions and ideas about the best way to determine what the best primary key of these tables should be, and pros and cons of all of the various approaches, but overall, that is not really what I am addressing.

Tables that relate entities, however, are a different story.

Suppose we have a system that tracks customers, and allows you to assign multiple products to multiple customers to indicate what they are eligible to order. This is called a many-to-many or N:N relation between Customers and Products. We already have a table of Products, and a table of Customers. The primary key of the Products table is ProductID, and the Customers table is CustomerID. Whether or not these “ID” columns are natural or surrogate, identity or GUID, numerical or text or codes, is irrelevant at this point.

What is relevant and important, and what I am here to discuss, is how we define our CustomerProducts table. This table relates customers to products, so the purpose of the table is to relate two entities that have already been defined in our database. Let’s also add a simple “OrderLimit” column which indicates how many of that product they are allowed to order. (This is just a simple example, any attribute will do). How should we define this table?

For some reason, a very common answer is that we simply create a table with 4 columns: One that stores the CustomerID, one that stores the ProductID we are relating it to, the Order Limit, and of course the primary key column which is an identity:

Create table CustomerProducts
(
   Customer_ProductID int identity primary key,
   CustomerID int references Customers(CustomerID) not null,
   ProductID int references Products(ProductID) not null,
   OrderLimit int not null
)

This is what I see in perhaps most of the databases that I’ve worked with over the years. The reason for designing a table in this manner? Honestly, I don’t know! I can only surmise that it is because of the lack of understanding what a primary key of a table really is, and that it can be something other than an identity and that it can be comprised of more than just a single column. As I mentioned, it seems that many database architects are simply not aware of this fact.

So then, what is the problem here? The primary issue is data integrity. This table allows me to enter the following data:

CustomerProductID    CustomerID    ProductID    OrderLimit
1                    1             100          25
2                    1             100          30

In the above data, what is the order limit for customerID #1, productID #100? Is it 25 or 30? There is no way to conclusively know for sure. Nothing in the database constrains this table so that we only have exactly one row per CustomerID/ProductID combination. Remember, our primary key is just an identity, which does not constrain anything.

Most database designs like this just assume (hope?) that the data will be always be OK and there will be no duplicates. The UI will handle this, of course! But even if you think that only one single form on one single application ever updates this table, you have to remember that data will always get in and out of your system in different ways. What happens if you upgrade your system and have to move the data over? What if you need certain transactions restored from a back up? What if you ever need to do a batch import to save valuable data entry time? Or to convert data from a new system that you are absorbing or integrating?

If you ever write a report or an application off of a system and simply assume that the data will be constrained a certain way, but the database itself does not guarantee that, you are either a) greatly over-engineering what should be a simple SQL statement to deal with the possibility of bad data or b) ignoring the possibility of bad data completely and setting yourself up for issues down the road. It's possible to constrain data properly, it's efficient, it's easy to do, and it simply must be done or you should not really be working with a database in the first place -- you are forgoing a very important advantage it provides.

So, to handle that issue with this table design, we need create a unique constraint on our CustomerID/ProductID columns:

create unique index cust_products_unique on CustomerProducts (CustomerID, ProductID)

Now, we are guaranteed that there will only be exactly one row per combination of CustomerID and ProductID. That handles that problem, our data now has integrity, so we seem to be all set, right?

Well, let’s remember the definition of what a primary key really is. It is the set of columns in a table that uniquely identify each row of data. Also, for a table to be normalized, all non-primary key columns in a table should be fully dependent on the primary key of that table.

Consider instead the following design:

Create table CustomerProducts
(
   CustomerID int references Customers(CustomerID) not null,
   ProductID int references Products(ProductID) not null,
   OrderLimit int not null,
   Primary key (CustomerID, ProductID)
)

Notice here that we have eliminated the identity column, and have instead defined a composite (multi-column) primary key as the combination of the CustomerID and ProductID columns. Therefore, we do not have to create an additional unique constraint. We also do not need an additional identity column that really serves no purpose. We have not only simplified our data model physically, but we’ve also made it more logically sound and the primary key of this table accurately explains what it is this table is modeling – the relationship of a CustomerID to a ProductID.

Going back to normalization, we also know that our OrderLimit column should be dependent on our primary key columns. Logically, our OrderLimit is determined based on the combination of a CustomerID and a ProductID, so physically this table design makes sense and is fully normalized. If our primary key is just a meaningless auto-generated identity column, it doesn’t make logical sense since our OrderLimit is not dependent on that.

Some people argue that having more than one column in a primary key “complicates things” or “makes things less efficient” rather than always using identity columns. This is simply not the case. We’ve already established that you must add additional unique constraints to your data to have integrity, so instead of just:

A single indexed composite primary key that uniquely constrains our data

we instead need:

An additional identity column
A primary key index on that identity column
An additional unique constraint on the columns that logically define the data

So we are actually adding complexity and overhead to our design, not simplifying! And we are requiring more memory and resources to store and manipulate data in our table.

In addition, let's remember that a data model can be a complicated thing. We have all kinds of tables that have primary keys defined that let us identify what they are modeling, and we have relations and constraints and data types and the rest. Ideally, you should be able to look at a table's primary key and understand what it is all about, and how it relates to other tables, and not need to basically ignore the primary key of a table and instead investigate unique constraints on that table to really determine what is going on! It simply makes no sense and adds unnecessary confusion and complication to your schema that is so easily avoided.

Some people will claim that being able to quickly label and identify the relation of a Product to a Customer with a single integer value makes things easier, but again we are over-complicating things. If we only know we are editing CustomerProductID #452 in our user interface, what does that tell us? Nothing! We need to select from the CustomerProducts table every time just to get the CustomerID and the ProductID that we are dealing with in order to display labels or descriptions or to get any related data from those tables. If, instead, we know that we are editing CustomerID #1 and productID #6 because we are using a true, natural primary key of our table, we don’t need to select from that table at all to get those two very important attributes.

There are lots of complexities and many ways to model things, and there are many complicated situations that I did not discuss here. I am really only scratching the surface. But my overall point is to at least be aware of composite primary keys, and the fact that a primary key is not always a single auto-generated column. There are pros and cons to many different approaches, from both a logical design and physical performance perspective, but please consider carefully the idea of making your primary keys count for something and don’t automatically assume that just tacking on identity columns to all of your tables will give you the best possible database design.

And, remember -- when it comes to defining your entities, I understand that using an identity or GUID or whatever you like instead of real-world data has advantages. It is when we relate entities that we should consider using those existing primary key columns from our entity tables (however you had defined them) to construct an intelligent and logical and accurate primary key for our entity relation table to avoid the need to create extra, additional identity columns and unique constraints.

see also:

The problem isn't the poor database model; It's that external code is bound to the schema

Jeff Smith — Wed, 15 Aug 2007 13:34:26 GMT

Dealing with poorly designed databases is a simple and common fact of life for programmers. It happens, sometimes due to lack of experience or education, or sometimes because business requirements were never analyzed properly or they changed. It's hard to avoid poor database designs, but it takes only a simple concept to make fixing those designs much easier. read more...

Distinguishing data from code

Jeff Smith — Tue, 24 Jul 2007 13:02:43 GMT

What is data, and what is code? How do we define the difference, and decide what goes where? It is great to say "keep data out of your code", but what if that data is integral to the application itself? Isn't it therefore code, and not data? read more...

Data Types -- The Easiest Part of Database Design

Jeff Smith — Tue, 03 Jul 2007 14:13:12 GMT

I see it time and time again in forums -- "dates" that don't sort properly, "numbers" that don't add correctly, "boolean" data with 10 different values, and so on ... Since we are rarely provided any DDL to review, it often takes many posts going back and forth until we finally realize: "wait ... you aren't using a datetime data type to store these dates?!" read more...

Retrieving Identity Values When Inserting Multiple Rows

Jeff Smith — Mon, 02 Jul 2007 16:31:17 GMT

You're INSERTing multiple rows from an un-normalized import table. Each row is assigned an identity primary key. You know you can use scope_identity() to retrieve one identity at a time, but how do you retrieve a whole set of them? Are cursors the only answer? As usual, it depends on having logical specifications and a good design. read more..

Passing an Array or Table Parameter to a Stored Procedure

Jeff Smith — Tue, 26 Jun 2007 13:36:11 GMT

SQL is a set-based language, and often we wish to pass sets of data as a parameter to a stored procedure. For example, you might wish to pass a set of Customers to an invoice generating stored procedure, or a set of employees for which you’d like to calculate a particular bonus. SQL Server already has everything you need to do this, and you don't need CSV or XML strings. read more...