Pls Explain Core Solution naming of relationships

[BruceJ]

I've started adhering to the standards available through Core Solutions. I like most of the concepts and since I don't intend to live forever, I want my solutions to be easily deciferable by another developer.

One thing that continues to plague me is the logic behind the naming of relationships. In the past I named them something logical - like "PatientZipCode". Instead, the Core Solutions standards would suggest I name this one: "zipCodes_#patientHomeZip#zip#patientDemographics"

The problem I run into is that sometimes I can't remember what the hell the relationship was generated for, especially those that serve some obscure function and may be based on calc fields not easily recognizable. Also - in some of the dialogues constructing layouts, and selecting fields, you can't read all of the realtionship name - this is difficult when you have a bunch of realtionships that are very similar.

Am I interpreting this standard wrong? I want to get it right in case I get hit by a Mac truck tomorrow, one of you guys/gals can take over my business! That's the only guarantee I have with my customers when they ask about the wisdom of buying a customized solution from a company that's a sole proprietorship - the open nature of my solutions for someone else to be able to come along and support them if I'm not around or choose not to.

[CobaltSky]

The problem with 'standards' is that they only become that if pretty much everyone agrees to always use the same set.

Given that there are a number of sets of proposed 'standards' in circulation, the purpose is partially defeated. Especially so when, as you are finding, some procedures recommended by a given standards framework may be good, sensible and workable, while others may be problematic. I don't happen to take the view that it helps anyone if a poor or unhelpful procedure is adopted simply in the interests of complying with a published 'standard'. I've been developing with FileMaker for more than ten years, but I've yet to see a standards document that I felt was workable in every respect in every situtation.

While I recognise that there is a particular logic driving the Core Solutions suggestions about relationship names, I think that the result is clumsy and unwieldy and creates more problems than it solves - some of which you have drawn attention to in your post. On balance, I don't personally think your clients, or for that matter, developers who may come after you will thank you for adhering to that aspect of the Core Solutions 'standards'.

I suspect, however, that you can achieve most if not all of what you want, by creating a text or pdf standards guideline document which is specific to each solution you create, which describes what conventions have been used - perhaps with a brief explanation. If possible, include the key details in an entry in the help file and perhaps also on a developer layout in one or more of the files. In this way you - and those that may come after - can enjoy most of the advantages of 'standards', while avoiding most of the disadvantages. You would then maintain an archive of all such documents and the solutions they applied to (you'll probably find that you can re-use the same ones frequently - or perhaps that you can get by with only one or two for all your work).

[BruceJ]

Going in another tangent -

CobaltSky - I checked out your website - wow! I really lek the undo and log file. My work is in medical databases and this will eb invaluable. Previously I had worked this type of thing out with clumbsy scripts, but yours is so unitrusive to the user! Good job!

[Anatoli]

Furthermore -- the "zipCodes_#patientHomeZip#zip#patientDemographics" will have probably problems in HTML/CDML code.

[Kurt Knippel]

Personally I use the following convention: "File by FieldName to FieldName". This fully describes the relationship setup, although not its purpose. However, I do not beleive that relationships need a "purpose" as this will lead to multiple relationships of the same setup since the purposes will be different and it is not possible to tell the nature of the relationship from the purpose. This also tends to be short, unless you have very long field names.