In this blog's history I have suggested naming conventions for tasks and components and just lately I have been experimenting with a naming convention for packages as well. I've been pretty pleased with it and today a colleague commented on its usefulness so I thought I would publish it here and see what you, the SSIS community, thought of it.
The thinking behind from it stems from the current development culture of defining namespaces for objects - a practice that is particularly prevelent in .Net development it seems. I realised that there wasn't really a way of defining a namespace for a SSIS package so I figured, why not manufacture a fake one instead.
The premise is simple. Each package name begins with the name of the project in which it resides at design-time. It ends with a description of that package's purpose. These two parts are then joined using the familiar dot notation. All parts of the name use CamelCase. The description of a package name follows a <Verb><Noun> nomenclature.
I can illustrate this better with a picture rather than words:
As you can the name of the projects inherit part of their names from the name of the solution and each package inherits part of its name from its parent project. The last part of the package name contains a verb followed by a noun.
Hopefully you can see the concept that I am driving at here. I like this approach for a few reasons:
The package names gives a clear indication of what the package does.
The casing adheres to common development practices
It helps to organise your packages at design-time into projects that serve a similar purpose
It gives a visual clue as to which packages do similar work instead of what a package does in isolation
It provides some context in which the package operates
It ensures that no two packages have the same name. This can be important when you deploy the packages to your test/QA/live environments - particularly if they are deployed to the same place..
Of course, there is an obvious disadvantage as well. The names are fairly long and unweildy. Anyone used to .Net development shouldn't have a problem with that however because we're not doing anything particularly different to how compiled .Net assemblies are named for placing in the GAC.
Also, another disadvantage is that the 'Name' property of a package (which is different to the name of the .dtsx file) cannot contain periods - they get replaced with a space. Hence, the name of the .dtsx file does not fully marry up with the name of the package container. I consider this to be a minor and inconsequential issue however.
So that is it. There's not much to it really, is there?
Does anyone think this is a useful technique?
Do you think you might employ this naming convention on your own projects?
Do you have any alternate suggestions for package naming conventions?
Let me know what you think. I'm really interested in feedback.
-Jamie
UPDATE 2006-11-17
I received an email in response to this post from Howard Wild. Howard shared with me his own package naming conventions and he has kindly allowed me to reproduce it below:
Here's what a typical package looks like - SLS_A_D_Dim_SalesRep, OK I know it's long winded but I also know it's a sales related package, it runs automatically on a daily basis and it generates the sales representatives dimension. On top of that there are slight deviations for import and export jobs eg TRN_A_W_ST2_Rch_JourneyHist, This ones a Transport related package, is automated weekly and brings in a base table form our Reach system, the table is the Journey History table.
We also use a very similar convention for Jobs.
We decided to choose this option because it best fits the way we work, being a Datawarehouse we are very business orientated and chose to group by business area above everything else. We acknowledge that in some circumstances business areas overlap and that some packages will have deal with multiple business areas and in those circumstances we tend to go with the original service requestor ie, the area of the business the person who requested the job works in.