What is the preferred way to document FM tables?
That would depend greatly on the individual developer, the sized of the developer team and the complexity of the solution.
OK, good start.
Single developer, app with 15 to 20 tables, very straightforward.
Then there wouldn't seem to be much need for documentation beyond good naming conventions and using the text box where needed in the relationships graph.
While in most cases I would consider external documentation I think you should go for this model:
You could also consider a model for your relational solution which is very easy to understand and to work with for even larger solutions. There are other good models, but I would consider using the "Anchor Buoy" model perhaps with the "Selector Connector" add on. But Anchor Buoy is probably enough.
Let me hear what you think, and if you need more I will have some suggestions for you to get to a higher level of documentation.
Have a look at this:
Six Fried Rice Methodology Part 2 – Anchor Buoy and Data Structures : SFR FileMaker Blog
I will also suggest that you use a set of conventions for all naming and order within your solution. There is not one correct way, but have a look here: Why FileMaker requires development standards - Coding Standards - FileMaker Coding Standards
You should also consider looking at this very old but still relevant input from FileMaker: https://www.filemaker.com/downloads/pdf/FMDev_ConvNov05.pdf
*For many reasons I believe you will be better of using FileMaker Pro Advanced for development. DDR generation is just one of them.
**You can not add notes and descriptions to the basic functionality of the DDR delivered by FileMaker.
***You can also generate the DDR as XML and read it into one of the many analytic tools delivered by third parties ... but first check and see if FileMakers build overview is enough for you.
The ddr overview
An example of the Anchor Buoy model
Hi Phill ....
Please forgive me, but is this not a very very brave statement?
ditto, Carsten! even when it's something small and for myself and beyond DDR, I:
The development process is an evolution and while I start with a spec outline (even for myself), it can go down a path that needs documentation as it evolves.
p.s. PDF screenshots (and PDF prints) can take MARKUP that is useful to make notes that are not possible directly in the DB.
Also: Have a look at this discussion: Anchor bouy . .. HELP! (Newbie)
And the next step could be this: FileMaker Data Modeling, Selector-Connector & Anchor-Buoy
I'd love to see a comment section on the Table screen in the same way we can create comments on the Field screen. If you agree, please vote: Comments at the Table Level
We usually create extra text blocks and write comments in them (at the RD)
Retrieving data ...