SQL Server for many versions has allowed for 128 Unicode characters when defining system names. A system name is used for a table, column, view, stored procedure or function, etc. The number of allowed characters allowed in SQL Server has changed over time, being restructured to 30 back in SQL Server 6.5. Other engines may have other constraints.
When responding to a previous editorial on removing the magic from our software, David comments how magic is not only used for variables, but has been used in database object naming. We are no longer constrained in ways we were decades ago. There is little reason to use cryptic naming conventions for our database objects.
One reason I have seen used is to obfuscate everything in order to protect intellectual property. Only those having access to the key to database object definitions can truly understand how things are designed. The last time I worked with Great Plains Accounting (over 15 years ago), this was the case. In fact, that was a key consulting profit stream to get the documentation and extend the capabilities or integrate with Great Plains Accounting.
Some would say you could use stored procedures for all database access, and encrypt the stored procedures for protection of intellectual properties. I’d caution against that idea. I know a couple of developers having figured out how to decrypt encrypted stored procedures.
I suppose you could use a utility similar to those we use with JavaScript to minify JavaScript code. Minification replaces variables with short variable names, removes spaces and code formatting, so that the code is as small, and succinct as possible. I don’t know if there is any such tool for SQL Server. It would be pretty cool if you could work with real names and intentions, and then have a pre-deployment stage modify everything to introduce your obfuscation.
The main point being made is the value of using a naming convention that takes advantage of the 128 Characters, and communicates clearly the intention of the SQL object. Sure, we could use extended properties in SQL Server, for additional information. That doesn’t transport to other engines well. Why not simply use names that clearly identify the intent?
Cheers,
Ben