Is there any best practice for grouping things visually in the Database Manager. I have a big import from another database which has over 200 fields and I want to group them for easier scanning. In the past I've created global number fields with names like:
----
------- Demographics
-----
With spaces after the hyphens so it doesn't say there's another field with the same name. In theory I could have prefaced every field name with Demographics like I did below with DailyAttendance, but that sometimes makes things harder, for example I can't just type: "DOB" in the data manager to jump to it if I change the name to Demographics_DOB
There are many field naming strategies and prefixing them to create groups is one of them. As you stated, it has caveats.
I tend to see prefixed field names in tables that are too wide (too many fields). It helps to group like fields but this assumes you know which group contains the field you are looking for. As you said, it sometimes makes things harder.
If it were me, I would split wide tables into narrower tables. For example, group the fields of the demographics example you give into its own table. The prefix is now the table name. You still need to know which table a field belongs to, but you now get to type the first characters of a field name without the grouping getting in the way.
I found prefixing field names is most useful when a group of fields is used to store same-state information. A same-state information is often displayed as a checkbox field in FileMaker, where one field can contain multiple pieces of information. This is generally discouraged in other database systems. Status flags are another such construct. The Get (ActiveModifierKeys) is one such example.
The above is just my opinion and take on the subject. It is, by all means, not the right or wrong answer. Other people will use different strategies that have their pros and cons. Choose the one you are the most confortable with.
Thanks for starting my favorite thread topic. I think organizing the manage database window is one of the most important steps to take to keep evolving complexity from getting the better of me, and I am always on the lookout for ways to improve my admittedly ad hoc set of tools for doing this.
My trick with the Manage Fields tab is to use underscores as prefixes to organize the table by field function.
I have a new table template with most of the standard fields already defined. I organize them so that the actual data fields (i.e. not meta data or other derived data or fields for managing relationships) are all the way at the end of my field list. I give them as human readable names as I can, and as you can see in my example file, where I have data group by categories, I use a grouping/underscore combo similar to yours.
This example is actually unusual for me because I typically don't use many summary or stored calculation fields; this app, however, is the perfect use for summary and calculation fields. Usually my Entity Data tables will be around 20 fields in total, with about half to ¾ being the various "housekeeping" fields I've described. This hyper-normalization alone makes it easier for me find my fields, because there usually aren't that many of them in any one table to begin with. Of course this doesn't help you when you're working with someone else's huge table, but the mantra of "skinny tables" really helps manage field complexity as much as anything.
Hope this is of some help to you. Have a great day!
Postscript: I know that using leading underscores can cause problems in other languages. For eSQL, I quote my field and table names, so this isn't a problem there, and so far just once I've had to use a custom function to take out leading underscores from field and table names for when I use the Execute FileMaker Data API script step.
What about using a tool like Developer Assistant and using a RegEx (if needed beyond a simple field name search) to scan for the fields you want? Wouldn't that approach be better than using ugly underscores or other hacks to fill in usability gaps that shouldn't exist in FMP (now in version 21....) to begin with?
Can you please elaborate? So for example if I'm adding a file to a layout, and want to find it quickly, or if I'm joining two fields together in relationship graph, or setting up an export script step... where does DA help? I feel like DA is a tool that I very much under-utilize so tips are appreciated.
DA can search any field, table, relationship graph using simple search terms or regular expressions. I've found it to be invaluable with huge relationship graphs, for example.
HTH
