Hello,

 

I'm still a novice, but I am beginning to understand the merits and drawbacks of the Anchor-Buoy method.

I've read Ray Cologon's "Approaches to Graph Modeling", and I've developed a modest database with the Anchor-Buoy method, but I don't think I have grasped yet the other methods in this paper to try them.

 

I'm starting a second, more ambituous, database, and I am going to begin using the Anchor-Buoy method.

I was wondering if there is any danger in using this method in terms of stability?

Does the abundance of TOs stress the operation of the database?

 

I know my fear might sound sophmoric...

 

Once I get more familiar with the nuances of FM developing I hope to move to a more sophisticated TO strategy as well as data separation methods.

 

But for now if anyone can assure me that developing with the Anchor-Buoy method should not lead to some fatal collapse of the database, it would be appreciated. Or warn me now to move to another TO method!

 

Thank you

 

Does the abundance of TOs stress the operation of the database?

 

Yes it does, as matter of principle and to avoid potential performance problems try to create as few TOs and relationships as you can get away with.  So question yourself everytime you want to add a relationship or TO and explore alternatives.

 

The FM12 ExecuteSQL function can help reduce the # of TOs and relationships.  Also familiarize yourself with the concept of TO hopping to help reduce the number of identical TO groups that are somewhat inherent to the A/B model.

After doing some more thinking and reading about this issue, it seems that the remedy to TO redundancy is "TO hopping" which generally

means a greater use of and dependency on scripting.

 

As I am gaining greater confidence in scripting, I feel much more comfortable straying from the A/B model.

 

If anyone can confirm my hunch, it would be greatly appreciated...

 

Thanks and Happy New Year to all!

You are correct, Not sure what you mean by "greater use and dependency on scripting".  If you mean as opposed to using calculated fields, then YES!  It's one area where the ease-of-use of FM through calculated fields will come back and bite you bad.  Those fields are easy to add but they will kill your performance and the solution's scalability after a certain point.  Whenever you feel like adding a calc field, think about using scripted set fields, look at the events that we can handle, look at the ExecuteSQL function and so on.

Thank you Wim Decorte. Your guidance has been very reassuring.

 

I have been trying to reduce the number of calculation fields in my first attempt at a database, as this seems to be the number one rule in improving performance.

 

I am unfamiliar with the Set Field script (if that is what you are referring to?), but I will now look into it!

Same thing with the ExecuteSQL function -- don't know what it is, but now will do some studying on it!

I don't have FM12, but hope to soon upgrade at our office.

 

Thank you again.