2 of 2 people found this helpful
The most important part of a naming convention is to use one.
The second most important part of a naming convention is that it be consistent.
The third most important part of a naming convention is that it be easy to read and understand (you don't want to spend time trying to figure out what the name means; slows you down).
Beyond that, you're rapidly going to get into the realm of "I like it this way", where every developer has tastes and preferences. I'm personally not a big fan of a lot of what's out there in naming conventions; I find most of them awkward, counterintuitive and unnecessarily noisy. So use what you find easy to understand. And stick with it.
For an example could you put what you would have within your solutions i.e.
Its just within my solution I have alot of ID fields inconsistent for example
Id, CustomerId or Customer_ID and foreign keys Customer_IDFK.
+1 to Mike.
Most important is dont use spaces because it unnecessarily complicates SQL and make data exchange with other systems painful
Here is an example:
Tables: UpperCamelCase, singular (Invoice)
Fields: lowerCamelCase (nameFirst); prefixes for derived data types: cSomeCalc, sSomeSummary
Keys: 'id' for the primary key, 'id_parentTable' for foreign keys
Scripts: UCC, as a verb (CreateLineItemsForSelectedProducts)
Custom Functions, their parameters: UCC, lCC - eg ToggleElementInList ( anElement ; aList ) - following the form of the existing functions
As has been noted, try to find something that makes sense to you, and be consistent.
After that, it's a matter of taste. I used to have table names in plural (there are many instances), but found the code to be more readable if it is in singular (it models one entity):
Customer::cNameFull, LineItem::priceExtended ...
Yes I guess so.
I would be happier with more definition between the primary and foreign keys. I'm only thinking so that they get sorted to the top of each table when viewing by field name.
1 of 1 people found this helpful
Do not make the mistake of prepending the underscore "_" before PK or FK fields. That may cause issues elsewhere. If you use lowercase "a" before, the sort will be good and the possible breakage solved.
Sent from miPhone
Having brief and uncomplicated names for the key fields outweighs for me any (perceived) disadvantage of them being not listed at the top. And they stick together anyway.
But hey, it's *your* convention so do as you please.
I winced a bit when I looked at the conventions Benjamin noted in post #1. I'm curious as to how many developers adhere to that convention?
I personally have never found that useful. I know it's been a "thing" for a lot of years (because it puts the keys at the top of the TOs on the Graph). However, I find it horribly counterintuitive. It's also not as useful as you might think, simply because you wind up opening the relationship dialog in most cases anyway to set relationship properties. So what I do is just drag the fields from one TO to the other, regardless of whether they're the right fields. Then, when you open up the relationship dialog, you just reset the fields while you're setting the other parameters.
I prefer to identify the keys with lower camel case "tableNameID". This gives me a very easy way always to identify the key with the table to which it belongs. I use a lot of DRY scripting, and having the key field with a predictable name across all tables is way more useful to me than tagging them with which one is primary and which one is foreign. If the table name matches, it's primary. If not, it's foreign.
But as I said, every developer has preferences, and generally has reasons for those preferences. Use what works for you.
I know they exist, that's it.
What about them qualifies as winceworthy?
About the only thing I use from that convention is lower camel case. Not crazy about most of the rest of it.
One of my biggest gripes is the custom sort on field names. While that sounds great if you're the one doing the sorting, it royally stinks if you're trying to come in behind someone else. I'm in the middle of a rebuild on a large system where they used the custom sorting, and it took me forever to get a grasp on what fields were where. If they're sorted alphabetically, it's really easy to find them.
One of the purposes for a naming convention is to make it easier not only on us, but on the poor slob who has to come in behind you. Having just dealt with that issue, I cringe at the custom field sort.
Also not crazy about the ALL CAPS with underscores for global fields. Ew. Hard to read, hard to type. (I HATE underscores with a hot hot hate.) And I've already discussed the naming of keys. I just prefer them to have the same name across all tables.