Working out how best to manage my “one source of truth” DB table, and deciding how to keep everything straight. Thought I would reach out for your best practices!
Right now I have the main Schedule Master table that holds all the info for a number of main ‘tasks’. Trying it this way because so much of the information duplicates and feeds into each other.
Call Sheets
Daily Production Report
Pre-Production schedule
Post Production schedule
As the volume of fields/columns grows (I’m up to 82 which may be nothing to you guys lol), I’m curious how you name and organize things. I’m testing out where one of the tasks/reports (the DPR) has fields that pertain only to that one report, so those fields begin with >. The thought being I will do the same for other reports; use a symbol specific to fields that ONLY go on that one. Haven’t decided how I feel about it lol
Having said that, I would suggest not to start field and table names with symbols, every now and again the formula builder gets confused if you do that. Develop a set of prefixes that works for you,
You may already be doing this, but when I have a table with a lot of columns, I’ll often create multiple backend views to simplify - group a view’s columns around a common workflow or persona.
At the very least, this means you don’t have to horizontal-scroll 80 columns when you want to check/edit something.
At the most, it means you can create separate layouts for those different workflows, so that when one person views the schedule they see only what’s relevant to them (and an ability to switch to other adjacent layouts)
Then I second @Piet_Strydom 's comments and add that the column description is one of the underused features for understanding the maker’s architectural choices. Not only is it the best way to overcome opaque column naming conventions but it can also be a great process/workflow aid when you need to explain the purpose or function of a column.
Then it takes just a quick bit of training for users to realize the value and start seeking that hover info.
Ooooh. Oh yes, that is something I keep forgetting is there! If I add a description right away when creating that could reduce confusion later.
What could be really useful for Coda to implement is if the description was visible (maybe in the hover info) in column lists to make it faster to determine if the field should be visible or not. But I digress…this is a great tip!
There is another very nice documentation tool: @Scott_Collier-Weir 's doc exploration pack. It allows you to automatically get a list of table fields in a new table.
I often use it when writing documentation for interfaces. It provides the basic Coda data about the field, I can then add a detailed description, codes and values if applicable and, in the case of fixed length reviews, the start column and number of characters.
