Doing Something About Auto Generated Names

I like my name. It provides a point of reference to who I am. If I am at work and someone calls for “Jason Strate”… that’s me. If I am at home, the same thing can happen and I still know that it’s me. I know that no matter where I am, my name will be a constant and it means something when it is called. Hopefully, it doesn’t mean “late to dinner”.

This same principle applies to the tables and the objects related to those tables. We give that table a name in the development environment, maybe it’s called “ZombieBaconUnicorn”. We expect that it will be called “ZombieBaconUnicorn”. Unfortunately, this doesn’t always ring true with other database objects related to tables; such as Primary Keys and Defaults Constraints.

Random Naming

There are multiple ways to create Primary Key and Default Constraints and they don’t all have an implied name. Take for instance the following script, what would you assume the names of the Primary Key and Default Constraints would be?

Non-Random Naming

Getting around the random naming is pretty simple. Below I’ll would you through the steps.

The first change is how you’ll define the PRIMARY KEY on the table with the CREATE TABLE statement. Instead of adding PRIMARY KEY CLUSTERED on the column definition, add it to the table as a constraint.

Next you want to use the ALTER TABLE statement to add the DEFAULT CONSTRAINT. Instead of making the default part of the column definition in the CREATE TABLE, you want to name the default as a constraint to name it as it is created.

SELECT name FROM sys.objects
WHERE parent_object_id = OBJECT_ID('dbo.NonRandomPKandDC')

On your server and mine the objects will have the same name. When you deploy objects build from T-SQL like this from development to test to production they will have the same names.

What the!?

Now there isn’t anything wrong with these random names from the perspective of how your database will perform. But it will hose up things such as database comparisons and investigating errors.

With database comparisons, the issue is pretty obvious. If the contents of the object are the same but the name is different then it isn’t the exact same object. Many tools have options for ignoring these names, but there are some that don’t. Even when the tool has the option to ignore, you will need to rely on the operator of the tool to disable the feature.

Looking now at investigating errors, I am a big fan of errors that can tell me the problem within the database. Which of the following is easier to understand. The first with the random name:

Ok, maybe this isn’t the best example of this type of issue, but it does tell me exactly the issue and because I named the object explicitly I know where the problem is and something about the issue before digging into the schema of the table.

Overall, this is about reducing pain points in building and using your databases. The easier it is to manage them once they are deployed, the more Bejeweled Blitz you can play on Facebook between your projects.

Renaming the Objects

Maybe I’ve sold you on this idea. If so, you may be thinking “What the heck do you do with all of my existing databases objects?” That answer is simple… rename them. Since the names of these objects isn’t tied to how they are defined, you can easily get them renamed with sp_rename.

The following two scripts are what I use to rename PRIMARY KEY CONSTRAINTS and DEFAULT CONSTRAINTS.

This first one will provide sp_rename statements that you can execute to rename all of your PRIMARY KEY CONSTRAINTS:

Conclusion

In a roundabout way, this post has been about naming conventions. Make the world a prettier place by having a convention on naming the objects in your database.

Last word… don’t just run out and use this in your production database without doing your own testing and promoting using your own company’s deployment process. An obvious statement but one that I thought I should point out since I know how tempting this can be.

I guess this is like the naming of a child when its born as opposed to the orphanage making up a name when they take on a child. Its really down to the ‘creators’ to decide on the appropriate name for everyone to use when they want to address the subject. Or maybe I have had more beer than I should have and am over the limit for reading SQL Blogs. Liking the rename scripts though, they could come in handy.
+1

You probably already know this, but I'll post it here for reference… The DEFAULT constraint name can be defined directly in the CREATE TABLE… no need to do a separate ALTER TABLE to establish names for any DEFAULTs:

I guess this is like the naming of a child when its born as opposed to the orphanage making up a name when they take on a child. Its really down to the 'creators' to decide on the appropriate name for everyone to use when they want to address the subject. Or maybe I have had more beer than I should have and am over the limit for reading SQL Blogs. Liking the rename scripts though, they could come in handy.