We made a mistake recently, breaking one of our own rules; Be Consistent.  Now, of course it is not always possible to ‘be consistent’, sometimes because you are doing something truly new; but often because one incorrectly sees differences – when you may be better off seeing patterns and similarities (and thus implementing something to fit an existing pattern)!

Within this picture of ‘consistency’ we also need to consider scope; and for the purposes of this post the desired scope is the system as-a-whole (including the whole system development life-cycle).  That’s going to be a struggle when different development companies / suppliers have written disparate parts of the system, or when the system is particularly large; but if you can be consistent in design, and folder structures, and so on, then you will reap benefits when the system is released, through consistency of release practices and locations and so on.  Of course, if different development-shops have coded different sections of the system it might not be relevant or necessary for coding standards to be similar – but it might be very helpful for interface guidelines and rules to be the same (in other words ‘it depends’).

And what was the simple mistake we made? We reorganised, consolidated and renamed some databases for our client; and decided the Live database should be called:

• SystemName

Obviously we used the actual name of the system,  but this will work for this post. We then decided that every other version of the database would have a postfix:

• SystemName_Postfix

The postfix would represent the environment; for example ‘Alpha’ test, ‘Integration’ test and so on.  We were being driven to alert users to the importance of live by not fitting in with the pattern used elsewhere* – but in fact that makes the assumption that everyone who needs to will know that ‘no postfix means live’!  Consider instead seeing a database name SystemName_Live – what do you interpret from that?

This split in naming rules also means that if we ever need to do any manipulation or parsing of database names in support or maintenance scripts or SQL then we will have to code two different approaches. Perhaps it would have been better to have only one naming approach?

Notes

* We have seen this broad naming strategy in use in several environments, and I would suppose it originates from the time when there was only a live system – that is to say that development was done against a database that ‘suddenly’ became the defacto live database.  As development practices improved you would copy the database, add the postfix ‘_Test’ to the name to distinguish it; and thus you are on the path to the naming approach we selected first.  That certainly occurred for one prior client.

Of course there are other strategies for naming databases for different development environments:

• Database name remains static, but the database instance is varied. i.e. Database name remains as SystemName, but the instance name is Alpha, Beta etc.
• Database name remains static, but the database server is varied. i.e. Database name remains as SystemName, but the server name is Alpha, Beta etc.
• Database per developer… or even per Ticket (e.g. every developer has their own cut-down database… and potentially every ticket has its own database).  In fact, when we consider the whole development life-cycle a number of these strategies might be used.