What’s In a Name? – Part 2
Last week in Part 1 I discussed the importance of naming a data element when it comes to aggregation, and reuse. Today I am going to consider the usefulness of table and column names themselves in a general perspective.
Unless your intention is to obfuscate the contents of your database, using good names for tables and columns is a great start at clarifying your intention. I’m not as worried about using singular table names (not ending the table name with the plural s (Customer not Customers). I find it more important to use table names that fully define the contents of the data.
If you use consistent casing for the table and column names such as Pascal Case, Camel Case, all lower or upper case delimited with the underscore character, it is less of a concern…just be consistent. Personally, I prefer using Capital first character for each word. Then when I have a join table such as Person_Role I am able to know by looking at the table name that it joins the Person table and the Role table using a many to many relationship.
Some databases are configured to be Case Specific in comparison so that Person, person, PERSON are all different. In this scenario, it can become more difficult to work with an inconsistent naming convention. Huge dividends are gained when using a case specific character set configuration and consistent naming.
In SQL Server you have thee SYSNAME data type which allows just over 100 characters. SYSNAME is the data type used for table names and column names. So, use the space to make your names clear and distinct. Table names such as AX, UI, EL, etc. require too much intemate knowledge of your business to be truly useful.
If you have longer table names and don’t wish to constantly type the entier name for readability reasons, I find it useful to have consistent Aliases. If someone doesn’t know what the Alias means they can simply look at the FROM or JOIN clause to determine alias intentions for tables. Reviewing the SELECT clause reveals the aliases for columns or formulas.
In short, think about what you would want to have if you were to come to a database designed by someone else. It may change your perspective as you create new tables.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
XML Support and SQL Server (Part 6)
This is the sixth part of my XML support and SQL Server article series. In this part, you will learn about the XML primary indexes and secondary indexes.
Featured White Paper(s)
Extending the Value of SCOM with Spotlight on SQL Server
read more)