Commandment 6: Unique Name on Spec
Within most of the Infinity database catalog tables, the NAME column contains a unique index that enforces a unique value within the NAME column for each row in the table. The NAME column within a catalog table is populated by the Name attribute for a specific spec type.
When a catalog item is loaded, a row is added to the appropriate catalog item table that contains the XML definition of that spec. For example, it you load a TableSpec, a row is added to the TABLECATALOG table. If you load a QueryViewSpec, a row is added to the QUERYVIEWCATALOG. This row contains a good deal of information about the spec as well as the entire spec XML. It is often useful to examine this data when troubleshooting issues. The metadata within these catalog tables are used to populate the feature metadata pages.
Let’s take a look in the database at one at the catalog tables used to hold the metadata for data lists. Within SQL Server Management Studio, I start by filtering the Tablesfolder within the appropriate database:
We filter the table names that contain the word CATALOG:
The result is a filtered listing of tables that contain the word CATALOG. When a particular spec is loaded to form a feature, the metadata for the spec lands in the appropriate catalog table.
Since we want to inspect the table that holds the metadata for data lists, let’s browse the DATALISTCATALOG table:
Now, let’s take a look at the indexes on the DATALISTCATALOG table:
Most catalog tables contain a unique index on the Name column to enforce a unique name for the feature. Future product feature names could possibly conflict with your custom feature name. Therefore it is important that you provide a name that won't conflict with future features authored by Blackbaud. Blackbaud Professional Services typically adds the words "(custom)" to the end of each name. This allows for easy identification of whether the spec was written by products or services, as well as guarantee a unique feature name.
The only exception to the "(custom)" name rule should be task specs, functional areas, and query views. There is no unique constraint on these from a database perspective, and it doesn't make sense from a UI standpoint to have the word "(custom)" in there.