I'm late to this thread and have scan read through it, so hopefully I won't duplicate some very valid suggestions above.
I believe we're in the minority here, but we always start our table occurrence names with the source table TO name and end up with the anchor table TO name. For instance, a TO based on quote line items, would be named QLI2Quote2Contact. The '2s' are historical and when pronounced 'QLI to Quote to Contact' makes sense to us. To re-emphasise, consistency is important, hence ILI2Invoice2Contact, or OLI2Order2Contact would be understandable variants.
Our namning convention is partly down to having been doing it this way for over 3 decades, but more so that, particularly in Windows, there have been, and I believe still are dialog windows that cannot be resized, hence using the converse of the above example of say Contact_Quote_QLI could appear in one of these window as Contact_Quot and there is no method of establishing the data source in one of these windows if it is at the end of the name. At the most basic level, if a layout is named the same as the TO it is based on, then we can immediately see what the source table is in browse mode within the Layout name displayed in the status area, but could not do so on longer TO names without going into layout mode.
Flexibility is important within the naming consistency. For instance, we have systems that have tables named 'Company' and 'Component', which with all the best will in the world, a 3 or 4 letter abbreviation results in 'Com' or 'Comp' for both. In this case, we simply accommodate longer TO names, often using the full table name if there could be any ambiguity.
There is no right and no wrong, as long as there is consistency throughout.
One other incredibly useful technique we use is to have a text note key in the top left of the relationship graph. For example, this could read:
1a - Contacts
1b - Companies
1c - Addresses
2a - Quotes
3a - Orders
3b - Remedials
4a - Invoices
5a - Purchase Orders
6a - Items
6b - Stock
6c - Goods In
7a - Human Resources
etc.
Each TO Group is separated from others by a text note containing one of the above values. Hence, if we want to go direct to Purchase Orders, as soon as the graph is open, we type 5a and are immediately taken to the correct TOG. Using this method we can jump around large relationship graphs. It is important to not start any text notes with dates or any other numerics, as it breaks this system. Hence, if we made a note we'd initial it first followed by the date and detail.
We come from an era where Claris/FileMaker Inc. published recommended naming conventions, which included a leading underscore for key fields. In the modern era this was as useful as using the '@' symbol as a find operator. Who was to know that email and SQL would be future features. Hence, we would not include any special characters in our table or TO names.
Regards
Andy
