Graph Tactics - Thoughts about organization
One of my favorite topics is clarity. Not just because it makes things easier to understand, especially in a shorter period of time, but also because it facilitates standards which make everything easier to understand - across solutions and developers. If everyone stuck to a few graph standards, then every time you open Define Database, you'll at least start to feel comfortable a bit faster.
Granted, not everyone's at the same level of development, however, you can always make your own database easier to understand - even if it's just yourself working on the file.
In this video, I talk with fellow developer Stephen Dolenski of FMForums.com. We talk about a technique which Stephen has been using to solve complex graph issues, plus some other tidbits about documentation and making your graph easier to work with.
If you need more information about different graph models then here's an older video where I covered those!
Comments
Some things I do.
Some things I do slightly different to both you guys...
I will colour a set of Anchor-buoy TO sets depending on the conceptual areas of my solution, usually the real-world departments. So, for instance, in one of my current solutions, I have 5 screens servicing the 'admin' office, each with it's own set of TO sets (one per screen), but all of those are coloured red. Then there are about 4 screens for the 'studio', each coloured blue. The interface for each section has a coloured header bar of the same colour that the users see, so there is a one-to-one relationship between visual interface and TO colour.
Within a TO group, in terms of naming, I'll use capital letters to indicate which entity a TO is based on, with the TO name reading from left to right:
OFFICE_QUOTES --> Office_Quotes__QUOTE_Portal --> Office_Quotes__Quote_Portal_CUSTOMER --> Office_Quotes__Quote_Portal_Customer_COMPANY_Details
That way they sort in a reasonably logical manner in pop-up menus when selecting them, and it's easy to see from the name what the entity is, without having to rely on the colour. The lowercase stuff after the entity name describes what the table is 'for', so it might be 'Portal' or 'Details'
I also use a variant of the one to one realtionship you show in the video to indicate selected items from a portal.
So the 'ADMIN_PRINTERS' TO is connected to an 'Admin_Printers__PRINTER_Portal', plus a TO of my GLOBALS table called 'Admin_Printers__Selected', which itself links to 'Admin_Printers__Selected_PRINTER'. My GLOBALS table is an exception to the rule of having it's name in caps in the TO title, but I know that's what it is by using a cartesian join between 'ADMIN_PRINTERS' and 'Admin_Printers__Selected' thus:
ADMIN_Printers::---| DATA --x--> Admin_Printers__Selected::---| GLOBALS
Where '---| DATA' and '---| GLOBALS' are empty text fields solely for use with the cartesian joins here.
--
Andy Warwick
Creed New Media
--
Andy Warwick
Graph Tips
I've started to use color a little differently. I use blue to mark a TO that supports record creation and I use red to mark a TO where records are deleted when the parent record is deleted. Typically, when you can delete records from a TO, you can also add records to it, but I've started to use Purple for a TO that supports both creating and deleting records. I use title separators like Matt. Sometimes I enclose the entire TOG, but I usually prefer a white background for my TOGs.
Use of Pipes
I've been using the double underscore (__) to separate TOG group names, but like Matt's use of the pipe (|) symbol. Are there any drawbacks/incompatibilities to using the pipe?
Don't know
Since I have not used the Instant web features of FileMaker for most of my FMP projects - nor the custom web publishing - I would not know. Maybe someone who has the web experience with FileMaker can chime in.
-- Matt Petrowsky - ISO FileMaker Magazine Editor