I cannot stress how important it is to follow a standard naming convention. When I first came to work at my current job the guy who initially set up many of the databases named things out of pure randomness. This made troubleshooting a lot more stressful than it had to be. There were databases named after animals (GrizzlyBear was a municipal tax code database), databases after the date they were created on (2005_11 was a GIS database containing business records) and a few databases that were simply named DB1, DB2, and so on...
The first thing I had to figure out when I started working was what each database was for, and without a standard naming convention and little documentation to go on it took quite some time to get everything straightened out!
Using proper naming conventions is something that should apply to all forms of computer usage. If you’re naming a file, function, or database choose a name that makes sense so people don’t have to scratch their heads figuring out what you were talking about.
When naming a database the absolute most important thing you need to include is what application or use the database fits. If you’re setting up a blog or wiki include the name of the blog or wiki you are setting up. If you’re configuring a database for an application include the name of the application. If your database is named after the purpose it serves you’ll be able to determine which each database is when you run backups and other forms of maintenance.
Next include the version name or a date at the end of the name to identify either the version number or the date when the database was created. These are two different approaches and depending on the situation one may better fit your needs than the other, but having at least one form how identification regarding the version or creation of the database will greatly help for maintenance. Sometimes dates work best. If you end up with a couple forked databases on your hands (perhaps one of your developers was a little over zealous with table maintenance) you can easily see which one came first. If you’re updating the structure of the database often versioning is probably best. This way v3.0 of your software can point to v3.0 of your database and everything stays in sync.
Well named databases:
Poorly named databases:
What was Steve's project?
Engineering is a department, so this name is to vague. Try including a project name or the purpose of the database like Engineering_Projects_2012, or Engineering_Raw_Data_2012
As long as you stick to an easy to read naming convention your databases will be much easier to manage. A good rule to keep in mind is what the engineers using your databases are going to think when they see your naming convention. Will they be confused? If so, you’re doing it wrong. If not, congratulations you have happy databases and your staff will thank you!