Using descriptive, consistent naming conventions is important and should not go overlooked. Variability and inconsistencies often lead to confusion, error and loss of time. It is not uncommon to come across tables and columns cluttered with abbreviations or shorthand that may be insightful to some, but enigmatic to others.
Consider the following table name as a basic example of a name that could use improvement.
T_ALL_SLS
Could be confusing or misinterpreted.
T_ALL_SALES
Ambiguity is removed with only two letters.
While length limits generally exist for schema/object/column names, by no means are they so restrictive that one must resort to being cryptic. Length caps do vary across products, but most are generous. Oracle has in place the 30 rule, allowing for 30 bytes for per schema/object/column. SQL Server allows for even greater flexibility, allowing for up to 128 characters per schema/object/column name. Make use of the length available and implement interpretive, meaningful naming conventions whenever possible. An important thing to consider when devising a name is how others might interpret it, could it come across and misleading or confusing? If ever in doubt, run it by someone unfamiliar with the data. In the end, taking time to choose a descriptive, well thought out name will benefit yourself and others later on.
Inconsistency too can be the cause of confusion and problems among names. It is not uncommon to come across fields that vary in name, but in actuality are referring to the same data. To prevent this prevent this from occurring develop naming standards, most importantly, use them. Rather than adhering to someone else’s ideal conventions, implement those that make sense to you and your team. Whether it be the addition of a prefix or inclusion of the application name, be sure those standards are identified, consistent, and known. Ensure others are aware of these standards and hold them accountable for maintaining them. Taking the time to think ahead and outline standards is worth the effort.
