Anchor buoy naming standards (table names with acronyms and underscores)

[ken_s2007]

I originally had table names that were upper-case acronyms, followed by an underscore, and more text: "MAC_address", "IP_address", "DNS_name".

After reviewing some of the AB materials, it struck me that there could be two problems in using those names in AB.

First, the uppercase acronyms could confuse things, since we (already) have (three character) upper case AB abbreviations in use with a specialized intention in AB.

Second, using an underscore would make (human) parsing of them in AB less obvious (since the underscore is an AB delimiter).

The best I've come up with so far is upper camel case, and no underscore for the source table name: MacAddress, IpAddress, DnsName. (If MacAddress were an anchor, that would be: MAC__MacAddress.)

On another matter, double underscore "COM__Computer" is customary (in the papers I've read) at the beginning of an anchor; the naming conventions paper* also has it in use for separating the "final SourceTableNameAbbreviation from the Source Table Name"*: "mac_IPA__IpAddress", although Roger Jacques' v. 2.2 AB paper only shows a single underscore in buoys. Pros/cons?

* http://www.filemaker...v_ConvNov05.pdf

[bcooney]

You eventually form your own style with AB, I believe. We name our tables all caps and as short as possible without being so obscure that someone else couldn't figure out what the abbreviation means.

For example, PEO for a People table. On the RG, we use the note tool to create a legend in the top left-hand corner that serves as a map to the TOs. In that note, we are descriptive of the table.

An example buoy name for the relationship People to Addresses (Preferred) would be:

peo_ADDR~pref

btw, your example table names are a bit questionable, as they appear to be field names not entities.

[ken_s2007]

Thanks for the feedback. The listed names actually are tables in this system: Computer --< MacAddress --< IpAddress --< DnsName. (IpAddress table only tracks manually-assigned IP addresses, not DHCP ones).

[David Jondreau]

I agree with Barbara. There's no one naming convention (though there are good people promoting one).

I use natural naming, pipes, and caps to get names like: contacts|CONTACT INFO preferred email

[Kilyaaan]

As i have not read the AB materials you refer to i may be somewhat off, but i just wanted to throw in where i have come to.

I have started using a notation inspired by object oriented thinking of table occurence names, and avoiding abreviations, posible giving some rather long TO names

like taking the example Computer --< MacAddress --< IpAddress --< DnsName

then if DnsName is anchor, the computer buoy would be

dnsName.ipAddress.cacAddress.computer

I use lower camelcase in all my Table names, (Upper case is for functions ) and i guess your problem with your underscore use in AB TO names, is eliminated with the use of a dot '.' as a seperator

Anchors will be the simple named TO's like:

dnsName

computer

I do use Underscore in TO names ( not table names ) but it is reserved for special cases like if the relation is through a global value thats selects something or something that is not plain table to table.

dnsName.selected_ipAddress.cacAddress.computer

The biggest problem with this is showing it on the table graph where you can get som pretty long boxes if you want to see the whole TO name. But you dont spend a long time in this view so its not a real problem.

What i feel is does is it really gives a nice clear view of what your working with.

And it inspires me to use the Let Function a lot as to cut out the long fieldnames in the actual calculation, making most calculations easier to read as well.

Before i ended at this I had also tried a lot of different naming conventions with several underscores and abreviations, never going back.

Good luck to all in finding the mehod that puts a smile on your face :)