Closed
Description
First, let me say, these are by far the best set of SQL and PL/SQL coding rules out there. Just about everything in them is great. I did have this one very strong quibble... Let me tell you, once it is adopted people just love it. So much less work and less thinking about things that don't matter.
Suggestion:
Table
Singular name of what is contained in the table.
There are many reasons why this is far better than plural names.
- In general, tables represent entities. Entities are singular. This encourages the (lost?) art of Entity-Relationship modeling.
- If all table names are singular, then you don't have to know if a table has a single row or multiple rows before you use it.
- What is the plural of news? lotus? knife? cactus? nucleus? There are so many words that are difficult and nonstandard to pluralize that it can add significant work to a project to 'figure out the plurals'.
- For non-native speakers of whatever language is being used for table names, point number 3 is magnified signicantly.
- Plurals add extra unnecessary length to table names.
- Bar far the biggest reason: There is no value in going through all the work to plural a table name. SQL statements often deal with a single row from a table with multiple rows, so you can't make the argument that employees is better than employee 'because the SQL will read better'.
Add a comment to the database dictionary for every table and every column in the table.
Optionally prefixed by a project abbreviation, but strongly consider schema separation for different projects.
Previously, the rule was:
Plural name of what is contained in the table (unless the table is designed to always hold one row only – then you should use a singular name)
Add a comment to the database dictionary for every table and every column in the table.
Optionally prefixed by a project abbreviation.
Metadata
Metadata
Assignees
Labels
New feature or requestNew feature or request