he sheer number of objects in a database makes keeping track of them difficult. Keeping track of objects dedicated to a particular table, such as constraints and column names, can be discerned by using sp_help @tablename or the information_schema views. The identification of other objects and their dependencies shared between objects are more problematic, as in the case of stored procedures accepting parameters. As your system grows in complexity, identifying the objects' dependencies and their purposes can quickly become confusing. The confusion multiplies after the creator of the objects moves on and his or her successor is faced with making sense out of the schema left behind.
Adopt a naming convention that limits the ambiguity and uncertainty surrounding an object and its purpose. The benefits of a consistent naming convention accrue exponentially as the number of objects under your control increases. Ten minutes spent in adopting a naming convention will help you, your co-workers, and successors keep track of your objects and their dependencies.
This month's 10-Minute Solution discusses some alternative naming conventions for database objects. You can ignore these suggestions in favor of something that makes more sense to your workgroup, but the benefits of consistency in naming database objects cannot be ignored.
As the number of objects in my database grows, how do I keep track of each of their dependencies and purposes?
Adopt a consistent naming convention to limit the ambiguity and uncertainty surrounding an object and its purpose. The benefits of your naming convention will accrue exponentially as the number of objects under your control increases.