Hello,
Each time when new project starts, I’m thinking about naming conventions of table and columns in database. Which case is your recommendation and why?
Case 1. column_name
Case 2. ColumnName
Case 3. Column_Name
Case 4. columnName
Hello,
Each time when new project starts, I’m thinking about naming conventions of table and columns in database. Which case is your recommendation and why?
Case 1. column_name
Case 2. ColumnName
Case 3. Column_Name
Case 4. columnName
I Like case 2, values seem to stand out to me better that way. Whatever you pick, keep it consistent!
I use case 2 (ColumnName) - because underscores are a pain to type.
Underscores are OK in index names, triggers, or other objects that aren't frequently typed. I leave them out of tables, columns, views, stored proc names since those are names that are frequently used and reaching for that underscore can slow you down if you use it often.
I agree with #2 for two reasons:
Coincidentally, I believe Java developers trend to use #4 in their classes. I'd change my answer to #4 if the client software is in Java.
Whatever you decide to choose, sticking to the same is most important, that is be consistent.
I prefer #2 as this is imo most readable and as mentioned before underscore is ugly and annoying to type. #4 is second best. #3 i like the least, both uppercase and underscore is overkill.
You should use case #1 because it's free of case sensitivity problems. Also, camel case sucks with acronyms.
columnID
columnId
columnIDAlternative
columnIdAlternative
RASCScore
RascScore
column_id
column_id_alternative
rasc_score
Also, spaces between words are visually more pleasant than jamming everything together. Absolutely worth whatever perceived pain of typing an underscore there is. Underscores simulate spaces and compound nouns and phrases have spaces in normal, written language. TheOnlyPeopleToTypeLikeThisMayHaveBeenTheRomans.
I vote for "Whichever one you used in the previous project" Consistency in this case is probably more important than any particular ideology...