Blog

It must be the geek in me that craves order, but I have never liked the out-of-box database names for SharePoint 2007. SharePoint uses a somewhat large set of databases for a farm installation combining configuration, search, and content databases. If you were to setup a normal SharePoint Farm using the suggested database names, it would look like this:

• SharePoint_ConfigN
• SharePoint_AdminContent_<Guid>
• SharedServicesN_DB
• SharedServicesN_Search_DB
• WSS_Content
• WSS_Search_<ComputerName>

There are a few of problems with this approach that become even more obvious when you install SharePoint on a database server that hosts more than one SharePoint Farm, and mix SharePoint databases with other application databases.

Some of the problems include:

• The default uniqueness strategy is inconsistent. In some cases, an incremental numeric identifier is used, but for the administration website, a Globally Unique Identifier is generated.
• The database names contain a mix of “SharePoint”, “WSS” and “SharedServices”  prefixes making it difficult to know which sets of databases are for SharePoint.
• None of these names are user-friendly in terms of grouping databases that belong to the same farm installation.

To mitigate these problems, I normally recommend to clients that they use an alternative naming convention, that follows this standard:

sp<farm>_<type>_<name>

The convention is designed to be both brief (relatively short), but contain all the information necessary to be human readable, and orderly.

To support this naming convention, databases are classified into 3 types:

• config – these databases hold  configuration settings
• search – these databases hold meta-information and configuration specific to search
• content – these databases hold content for web applications/site collections

Below is an example of an installation using this convention. The SQL Server hosts two farms: a Development Integration farm for building and unit testing SharePoint solutions, and a QA/Testing server for doing user acceptance testing.

spdev_config_farm spdev_search_farm spdev_content_centraladmin spdev_config_ssp1 spdev_search_ssp1 spdev_content_ssp1admin spdev_content_mysites spdev_content_intranet

sptest_config_farm sptest_search_farm sptest_content_centraladmin sptest_config_ssp1 sptest_search_ssp1 sptest_content_ssp1admin sptest_content_mysites sptest_content_intranet

I believe most people would agree this is much easier to read and manage than the defaults. The only obstacle to achieving this standard is that by default, the SharePoint Products and Technologies Configuration Wizard creates the first two farm databases for you using hard-code defaults. Specifically, the farm configuration database (SharePoint_Config), and the central administration content database (SharePoint_AdminContent_<Guid>).

To resolve this problem, SharePoint includes a command-line utility called PSCONFIG.EXE that can be used to pre-create the initial farm databases. To learn more, see my blog post on how to Manually create SharePoint Farm databases with PSCONFIG.

Additional Information

• For a more complete overview on the standard SharePoint databases, read the Microsoft TechNet Database types and descriptions (Microsoft SharePoint Server).