0

I would like to know if there are any drawbacks to having descriptive names for database tables and columns. This would be for a Java based web application, and most of the times I have seen database tables or columns, they have had abbreviations for the tables and columns, such as "CD" when referring to "Code". Would there be any performance issues if the names of tables and columns are a bit fuller to increase readability of the Java classes that would get generated by JPA, even if it means reaching the upper limit for the allowed lengths for table and column names? There would be hundreds of tables in this application (enterprise app).

Thank you.

2

You need to find a balance.

AnIncrediblyLongVariableOrTableName is almost as hard to deal with as TooShrt - especially when you're looking at a block of code (or a sproc) that mentions a half dozen of them within 20 lines.

If the names are too long, you'll see a significant performance hit - in your developer's brains. It will be harder to read the code, harder to fix it, harder to enhance it, etc. Hard to read code can add hours or days to the development cycle.

From a computer performance point of view, I'd be astonished if you could measure a significant difference between hyper short names and ridiculously long names.

| improve this answer | |
  • That's what I was thinking, finding a balance. But are there any quantitative drawbacks that could be meaningful or would it be a negligible performance impact as the names get longer? – ITWorker Dec 23 '16 at 19:23
  • Probably not. I've updated my answer – Dan Pichelman Dec 23 '16 at 19:29
2

There's a limt on how long column names can be in mosd DBMSes: Postgres and MySQL allow 64 characters, Oracle only 30.

It's fine when you have a long name for something primary, but once you start considering related tables, you might need to combine FK column names to show their relationship. For instance, if you have an worldwide_catalog_id column on an agriculture_product table, and add it as an FK to a recurring_customer table as a favorite, you might end up referring to it as recurring_customer.favorite_product_wordwide_catalog_id. It may be acceptable from the readability POV, but you may end up hitting DBMS limits.

Use column comments to precisely explain the purpose of a specific column.

Try being pragmatic introducing shorter column names. Maintain a thesaurus for that, a list of uniform common abbreviations, etc, so that new developers have easier time picking it up, and you yourself don't forget.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.