Strong database names on database server

Question

We have a SQL server with many databases in it. We have customers with multiple versions of a similar app and multiple apps for a single customer. Almost all databases are tied to specific websites.

How do you stay organized with your database names? Surely there is no single answer, but do you have a database naming strategy that is working for you?

We are considering:

Customer + Product + Phase of Development (Production, Staging, etc.)

But that becomes awkward when a customer runs three versions of a product.

Answer 1

Creating a Developmestuction where you have multiple instances of the same database (Dev, Production) on the same database server is just asking for trouble. If you can't get a second server (physical or virtual), you should consider creating separate instances of SQL Server.

Your databases name should reflect how you internally refer to the applications. You wrote:

We have customers with multiple versions of a similar app and multiple apps for a single customer

It's not clear what you mean. Do take one of your "base" applications and then customize the application for different clients? Do you create completely different applications for different clients? Is it a mixture of both?

My assumption is that you start by developing a one-off application and, if another client likes it, use that as a base application for future customers. Based on that, it would make sense to refer to your applications by name+customer, and name your databases accordingly.

• SalesManager_Wilco
• SalesManager_AbcInc
• SalesManager_Internal
• TimesheetKeeper_Internal
• ExpenseTracker_Wilco
• HelpBuilder_Wilco

Answer 2

Our naming strategy is usually based on the concatenation of 'three letters acronyms' (TLA's) representing the different 'dimensions', of the database, separated by underscores. This rule is applied for sites, applications, clients, etc.

For example, when my app acronym is ABC, and our United Emirates Office is a suscriber to the ABC database, this database name will then be ABC_UAE (Using then the offical/ISO TLA of the country is of course a nice choice).

Once you give your clients a TLA identifier, you can use it to build your database name:

• ABC_ACM: for the main/central ABC database for Acme Company
• ABC_ACM_CAN: for its subscriber's in Canada

Now, if you maintain different database versions, you have the choice between:

• ABC_012_ACM if version 1.2 is maintained for multiple clients

• ABC_ACM_012 if Acme has its specific 1.2 version

In case these databases have subcribers, the meaning of ABC_ACM_012_CAN is then quite obvious. I'd advise you to use a standard 3 digits numbering for version numbers. It makes things really easier!

This rule suffers some exception when talking about development databases. For example, my developer's version of ABC_ACM database will be ABC_ACM_pgrondier, if development is maintained by client, or ABC_012_pgrondier if development is maintained by version. As a matter of fact, having the last 'dimension' of the database name not implementing the TLA rule is also quite common when you come to individual suscribers:

• ABC_ACM_012_username is subcriber to ABC_ACM_012

• ABC_ACM_012_CAN_username is subcriber to ABC_ACM_012_CAN