seeking tutorials for TO's and TOG's

[noamb]

Hello everybody,

 

I'm just returning to FileMaker development after years away. The last time I developed in FileMaker was... version 6!!! Wow, has a lot changed, and thank goodness it has.

 

I'm trying to understand FileMaker database schema design. I have a decent knowledge of normalized database forms, but the concepts of having multiple Table Occurrences, and Table Occurrence Groups, are quite foreign to me. I understand what they are on the Relationship Graph, but I don't yet understand how to plan and use them while constructing my solutions.

 

Can you direct me to some good tutorials on these topics? I imagine I'll need to examine more than one tutorial (and sample files) in order to truly grasp the concepts, so the more the better!

 

Many thanks!

 

[Mark Scott]

Hello noamb,

Welcome back to the FileMaker fold.  A lot has changed indeed!

Can you direct me to some good tutorials on these topics?

Here's the tutorial you should start with, by FM Guru Ray Cologon.  I think it's just what you're looking for!

There are others, but start with Ray's white paper.

Then, when you're ready for a slightly more advanced approach, check out Todd Geist's video on the recent innovation of the Selector-Connector model, which builds on some of the concepts in Ray's paper, adding a further level of abstraction and flexibility.  This approach, developed jointly by Todd and Jason Young, has been generating a lot of buzz over the past year.

hth,

Mark

[Lee Smith]

Hi noamb

You posted this in the General Topic for v14, but have listed your version as v9? Please update your profile if you have changed versions.

 

Edited August 27, 2015 by Lee Smith

[noamb]

Nope, I'm in v14 Advanced. 

[comment]

The last time I developed in FileMaker was... version 6!!! Wow, has a lot changed

Indeed, and most of it has changed when version 7 was introduced. To grasp these changes, you absolutely must read the "Migration Foundations and Methodologies" document, available from http://www.filemaker.com/downloads/pdf/techbrief_fm8_migrtn_found.pdf

[Tom R.]

I second Mark's recommendation of Todd Geist's video on Selector Connector model. There's a video on youtube that I found helpful in addition to Todd's video. Matt Petrowski does a good job explaining things for people - such as myself - who are not on quite such an advanced level. https://www.youtube.com/watch?v=ml-WF7qfMB0. 

[noamb]

Ray's paper does indeed look very useful. I'll take a look! I've already watched Todd's video on Selector Connector and I imagine I'll come back to it again after reading Ray's paper. I downloaded and investigated Todd's sample file but I found it was so full of many varied kinds of techniques that I couldn't figure out which was Selector Connector and which was other stuff (like Master List, etc.).

Thanks!

[Lee Smith]

There are these sites too.

http://learningfilemaker.com by RCConsulting

http://www.lynda.com/FileMaker-Pro-training-tutorials/199-0.html by Cris Ippolite

http://dev-www.soliantconsulting.com/soliant-tv By several experts

and there are more.

Edited August 27, 2015 by Lee Smith

[Gabriel G]

Hi noamb,

I found this site to be helpful. It's a nice break through with the v6 to v7/8 transition.

http://www.kevinfrank.com/anchor-buoy.html

Good luck to ya!

[noamb]

Thanks, that's helpful!

Any suggestions on resources for how to name TO's?

[Tom R.]

What sort of system are you trying to model, and what are some of the tables you plan to use?

Depending on what sort of graph model you adopt, it may make a difference.

I think the standard for Anchor-Buoy is to use 3 or 4 letter acronyms for your table, and then name the TO based on it's position in the TO group. For example, a table occurrence group consisting of People, Addressses and Phone Numbers, where the People TO is the Anchor, I would name People "PPL" (or similar), Addresses "ppl_ADDR"; and Phone Numbers "ppl_PHON". The point being to put the name of the actual table in all-caps, and to prepend the names of the anchor table and any preceding buoy tables in lower case. 

For join tables, I sometimes just use the two names of the tables to be joined as the name of the join table; for example, a join table between people and events I might name "PersonEvents"; but depending on your model, the join table might store additional info and have its own purpose, so you could call it "Registrations" instead of PersonEvents. 

There's website called Filemaker Standards (http://filemakerstandards.org/display/cs/Overview) that has lots of info on coding standards, naming standards, and so forth; but their standards are a little arcane, and from my perspective as an intermediate level developer, somewhat hard to grasp in some respects. 

If I were in your situation, I would be inclined to learn Anchor-Buoy first and get used to that. Then after your comfortable, you could move on to Selector Connector, which actually can be used in conjunction with anchor-buoy, rather than a complete replacement of it. 

Hope this helps.

Tom

Edited August 28, 2015 by Tom R.
Added screenshot of example TOC

[Wim Decorte]

Ray's paper does indeed look very useful. I'll take a look! I've already watched Todd's video on Selector Connector and I imagine I'll come back to it again after reading Ray's paper. I downloaded and investigated Todd's sample file but I found it was so full of many varied kinds of techniques that I couldn't figure out which was Selector Connector and which was other stuff (like Master List, etc.).

Thanks!

Start with Ray's whitepaper.  Especially get into a good understanding of A/B.  Todd's Selector/Connector is not in Ray's paper because it is a fairly new approach.  I strongly suggest that you not jump into that one feet first without a solid understanding of where it descends from. 

Edited August 28, 2015 by Wim Decorte

[Mark Scott]

Any suggestions on resources for how to name TO's?

There are several different naming-convention approaches that developers have used, not just for TOs, but tables, fields, variables, functions, etc. as well, some a bit more "geeky" and others more slanted toward being "highly readable."  I like the naming conventions and coding practices promoted at FMStandards.org, which tend toward the "highly readable" camp, but YMM, of course, V.

Mark