Paul,
I really appreciate your post. I have seen may responses to these questions about sequencing in a database with very few offering any practical advice beyond saying redesign your database or use built-in database sequencing (IDENTITY, AUTO_NUMBER, and so on). There is a lot of talk about concurrency issues without providing solutions to real problems. Here we have a practical solution and as good as it seems; you wisely express caution in its use.
I have not ignored all of the warnings about going outside the built-in database support for sequencing and so I have a question about other techniques to achieve the sequencing that is not quite fulfilled by SQL Server’s identity. There are places in a database design where you need a set of objects, but not so many are anticipated that the user cannot keep track of them without identifiers. I like to call these unnamed objects. I subscribe to using natural keys rather than surrogates in nearly every situation and so a table containing the set of unnamed objects will typically have a compound foreign key to a named object. Even though the object is unidentified to the user, it needs to be identified to the database and this is where a database generated identifier comes in. I will use an identity as a primary key here, but when the unnamed object table has dependent objects, I am never sure what to do with the foreign key in this other table. Should the primary key which is an identity become the foreign key to the new dependent object table? Should I make the new foreign key compound using both the identity and foreign key from the unnamed object? Now I have another seemingly robust and concurrency safe option to generate a sequence that is unique only to the foreign key rather than the entire unnamed object table. I would modify the Allocate_TSQL procedure to use the compound primary key of the named object instead of SequenceName with similar changes to the SequenceTable. Now I can have a more natural key for any table of objects dependant on the unnamed object. I know that the identity will work, but I am not all that comfortable with either of the other solutions for my foreign key dilemma. This new option seems right here and tables dependent on the unnamed object have a proper foreign key. Even if the unnamed object table is not involved in a query, the table dependent on the unnamed object can be joined to the named object table; the unnamed object table is not needed in these queries. This scenario happens at times and although it is simple to join in the unnamed object table, it just seems right to me to continue using the natural key developed for the named object.
So, is the sequence table right for this application or is this just a case of a stubborn natural key advocate trying desperately to hold on to what makes sense to him?
.png)
