You need more bots. LOL
1 Like
@jormond is already at the next level: Clones. (drones & bots can only get you so far)
It goes sideways... I know better. Calvin Meet Calvin Meet Calvin | Read Comic Strips at GoComics
1 Like
Or one that still has me hoping!
And one that is looking more likely Idiocracy (2006) - IMDb
1 Like
The older I get, the more fastidious I become with naming conventions, and the more grumpy I become when I have to work with someone else's!
I tend to stick with a very simple formula:
SOURCETABLENAME | nextrelatedtable | nextrelatedtable.matchkeydefinition
e.g:
CLIENTS | invoices | product.productID
The main thing for me is consistency in the spelling and formatting, so that when selecting from a list, the TO's are all nicely grouped together...
5 Likes
We use a similar approach, but we are careful to use web-safe characters only.
anchor_buoy_BASETABLE__purpose
inv_ili_CLI__ActiveClients
3 Likes
Below are some "FileMaker Relationship Graph Standards" we use (working mostly on macOS).
PDF here...
http://www.twdesigns.com/resources/documentation/f/filemaker-relationship-graph-standards/
1 Like
Anchor Buoy is like socialism — among its adherents are a lot of people who use the term rather loosely to refer, in a vague wave-of-the-hand way, to any implementation that addresses certain concerns; and yet there are others who still connect the term to some very specific approaches some of which are very offputting to a wide range of critics.
Things I detest about formal-recipe Anchor Buoy:
a) The notion that you would have a TO on the left edge for each and every native table, so that you end up not merely with Jobs and Clients, linked by ClientID = ClientID, but instead have Jobs connected to Jobs_to_Clients and farther down you have Clients linked to Clients_to_Jobs by the exact same fields. This is redundant and unnecessary and klunky as all getout.
b) The Naming Convention from Hell. I hate inheriting systems that have TOs with names like Jobs_to_Clients_to_ClientContacts_to_TelCalls or whatever.
c) The plethora of additional prefixes and suffixes that permeate both the TO naming and the field naming conventions.
If, after working in the system fulltime for a month, I can't freehand-type the name of the most commonly used TOs and fieldnames and get them right, they're badly named.
There is less deployment and hence call for type-ahead in the old sense of scooting you down to the correct element in a long vertical list, but the guess-as-you-type version still makes it important to not have dozens of elements that start off with the same character strings. Elements should have simple names that reflect what they actually are. Tertiary and ancillary TOs may need to have names like POitemsViaExpiredOrders but the primary ones should have names like Tracks and Tickets and Orders and Students and so on.
I hate underscores. They are cumbersome to type. Having more than one of them consecutively is sufficient cause for violence. If I see them I will pick up a rake and I will kill them on sight.
2 Likes
You are going to have to fight millions of devs over this one. It's one of the few web safe characters.
I love this quote though!
Nice rant, @AHunter3! 
Like any convention, anchor-buoy can be used in different ways...
The challenge is getting your own brain wrapped around someone else's ideas and concept.
You confirm what I always suspected: some TOs are more equal than other TOs
2 Likes