Today I’m circling back around to an old conversation about naming conventions. I’m going to focus on SQL objects, but the concept still applies to any other application that names objects or variables.
Over that last few months I’ve come across some interesting naming conventions for SQL Objects. Some are old school and others are new to me.
For example, one company does not like to create tables ending with S, because each record is a singular instance, and the table is simply a container. There has been a lot of different opinions on this topic, and personally, I don’t really care. I would name tables using the ploural notation for the same reason I name a collection in C# using plural.
Class Email
var Emails = List<Email>
Why not do the same with tables? One company solved the issue by simply putting a suffix on the table of _S. That way instead of having an Emails table, you have an Email_S table. I guess the underscore solves the problem.
Others are still naming tables with a tbl prefix. This is in an effort to distinguish a table from a view. I can see some value in that simply because tables are materialized and views are not. I tend to do a similar thing with user defined functions so that you can differentiate a table value function from a scalar function, because they are consumed differently.
Even so, I’m not sure there is a lot of value to these prefixes and suffixes. If there really is, then why don’t we go all the way and create prefixes or suffixes to our column names or variables? Maybe you do that too. However, it has long been a practice to not prefix variables and column names with data type identifiers. Is there a one size fits all concept.
If this sounds like trolling that is not my intention. None of these examples break anything, nor do they reduce comprehension. It is simply more an issue of preference I would think. What do you think? Drop a comment here or by email to btaylor@sswug.org if you want to share your opinion.
Cheers,
Ben