I wonder what are the pros and cons of having one huge table with multiple columns vs having one master table with accessory ones.
In my project, i have one master table with a P&L: revenues, cost, interest, depreciation, ebitda etc.
In parallel, I have multiple tables with details. For example, one table is called Revenues Detail and i have the three sources of revenues plus a total revenue column which I Lookup to the master table. The key to connect tables is the month/year.
I find it easier to organize this way, but feels like i am breaking a basic rule of databases.
Each setup is different, and there isn’t a single right answer, so it’s definitely up to you as far as what works best for your flow.
In general I’d say that information in a master table is easier to work with and use in other ways. A strategy I use is to figure out what the smallest, or most detailed, chunk of info that I need is, then include anything that matches that level of granularity in that master table.
A financial example of this might be a per-trade level. For this I need to know bought or sold, amount, price, date, item, etc. Anything that I need to understand that particular trade I would include in that table.
Then, for summary items, a monthly roll up or total, I would use a separate table that uses filters and lookups to the master table. So purchase totals per month could be a separate summary table, but using data from the master table.
Lastly, I make good use of lookup columns in Coda. If I have a company listed, I might use a separate table for companies with all of the company info I need, then reference that table in any others where I need companies listed.
Again, every doc setup is different and has its own requirements, and there are quite a few ways to make the same thing happen. If you have an example that you can share here publicly, we might be able to help a little more.