SQL: Try to avoid unnecessary abbreviations when naming objects

There’s an old joke in computing about how you can spend 90% of the time on a project working out what to name things, and end up without time for doing the work.

Phil Karlton is credited with having said: There are only two hard problems in Computer Science: cache invalidation and naming things.

I really liked Jeff Atwood’s or Leon Bambrick’s update though: There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. (Can’t work out who said it first).

Today’s post is just a simple plea to ask you that when you’re naming things, to avoid abbreviations that aren’t necessary.

I’ll give you a few examples of what I mean.

EOMONTH

SQL Server 2012 introduced a new function EOMONTH. It’s End of Month. I recently wrote about how it does more than just take a date and give you the end of the month for that date. If you missed the discussion, that’s here.

But what I want to talk about today is why on earth it’s not called ENDOFMONTH, or perhaps better, END_OF_MONTH.

What’s the real value in saving three characters from ENDOFMONTH to make it EOMONTH anyway? Keep in mind that the same version of SQL Server introduced a function DATETIMEOFFSETFROMPARTS, so it wasn’t just about saving keystrokes.

When I asked the product group, I was told that they copied the name of the function that’s in Excel. I really don’t like the idea that the name of new SQL Server functions would be based on what someone came up with in Excel a long time ago.

Database Objects

Anyone got any idea what aptrx is as a table name? If you’ve been around a while, you might guess that it’s Accounts Payable Transactions. But is there really any need to intentionally obscure the database like this, and not use a name like AccountsPayable.Transactions?

I’m sure this originated on older systems where short names were all you could have. I’ve worked on ancient systems where a table name needed to fit in 6 characters. Even today, I think Oracle is limited to 30. But most sensible database systems allow for longer names if you need them. Object names in SQL Server are of datatype sysname which is currently mapped to nvarchar(128). Length really isn’t a justification anymore, and most modern UI’s write the names out for you anyway, so it’s not even a typing issue most of the time.

Shortened names provide no real benefit and add to maintenance and support costs.

2019-09-05