Call me picky, but I think it’s important to consistently name your SharePoint databases—especially on a shared SQL Server hosting multiple farms and applications.  Not only is it a good practice, but by showing that you care about the databases, you’ll earn the respect of even your most grumpiest DBAs.  I wish the SharePoint administrative interfaces ushered you into a naming convention, but the reality is that consistent naming requires diligence and a little planning.  I would bet that a majority of the SharePoint installations in the wild were configured using using the Products and Technology Wizard GUI.  When you use the GUI, it creates the Central Administration content database without giving you the opportunity to provide a meaningful name.  If you’ve seen a database named SharePoint_AdminContent_[YOURGUIDHERE], you know what I’m talking about.  Imagine you are supporting multiple SharePoint farms—is it easy to tell which database belongs to which farm?  Shouldn’t it be?

Naming Convention

Here is the naming convention I recommend for SharePoint 2007:

SharePoint_[Farm Name]_[Database Type]_[Name] where database type is one of the following:

• Config
• Content
• WSSSearch
• SSP
• SSPSearch

For example, the AdventureWorks MOSS 2007 Enterprise Intranet farm would have the following databases:

What I like about this naming convention is that the databases sort nicely.  On a shared SQL Server, the SharePoint databases are separated from other application databases.  Within SharePoint, each farm’s databases are together.  Within each farm, the database types are together, and finally, a meaningful name makes it easy to determine which area it belongs to.

Implementing the Naming Convention

The best way to ensure consistency is to script configuration changes.  I use PowerShell to tear down and build up my development environment, and I use the same approach to make changes to production servers.  In a future post, I will provide a sample, but essentially, I create a script that takes an environment-specific XML configuration file as a parameter.  For example:

Provision-Farm.ps1 johnpowell.development.xml

If you are lucky and brilliant enough to have a naming convention in place before the farm has been configured, it is much easier to implement the database naming convention.  Implementing a standard after the fact will require additional steps.  So let’s suppose you just installed the SharePoint bits and are ready to configure SharePoint.  Stop!  Rather than use the GUI, use PSConfig from the command line.  This enables you to control the Central Administration content database name.  For example, to create the configuration and CA database, use the following command:

psconfig.exe -cmd configdb -create –server sqlcluster.aw.com -database SharePoint_AWIntranet_Config -user svc-sp-aw-farm -password pass@word1 -admincontentdatabase SharePoint_AWIntranet_Content_CA

But what if you have an existing farm?  In that case, this post describes how to rename the Central Administration content database and this post outlines the procedure for renaming other content databases.

Conclusion

It is good practice to have a database naming convention, and to define and document it during the planning phase.  Although the SharePoint administrative interfaces do not enforce a database naming convention, with a little planning and governance you can implement a standard.  Once a standard is defined, scripting configuration changes is the best way to ensure they are implemented consistently.  For example, you could have a script Create-WebApplication.ps1 that takes a few parameters and implements your naming convention.  SharePoint 2010 has significantly more databases that 2007, making database naming even more important.  So here are your “go dos:”

• Define and document a database naming standard
• Create scripts to implement your standards
• Evaluate existing farms against your standards, and create a plan to rename them