10 min read
Coda at scale: managing table counts
How to identify and address docs with high table counts
What you'll learn:
- How to determine table count.
- Risks of having too many tables.
- Tips for reducing table count.
- Scalable doc schemas.
What you'll use:
Checking table count
Use the doc map to see a list and count of all the tables in your doc. Table count is listed at the very top.
Risks of having too many tables
There are 3 main reasons that having too many tables in a doc is risky.Data connectivity
When you have data spread across independent tables, it’s not connected in the same way as it would be in connected views. Let’s explore an example: A “meeting notes” doc where a brand new “action items” table is generated for every single team meeting. Because these are independent tables and not views of a central “all action items” table, the team is not able to:- Compare entries across all meetings.
- Easily calculate how many total action items have ever been created.
- Pull a list of all incomplete action items across all meetings.
- See a personalized list of all of their assigned action items across all meetings.
Usability
Let's be honest, who likes clutter? If you have 50+ tables that are all unique and therefore could not be consolidated into views, this may be a sign that you have too much going on in one doc. Docs that house many different topics or workflows can become difficult to use and navigate, and finding specific information within the doc becomes challenging. It is often the case in larger docs that not every section is relevant to every user. This means users are spending more time sifting through irrelevant content, searching for the right page, and the right table, to find what they need. This can lead to inefficiency and frustration for your users. Not sure what should stay and what should go? Learn more about what should get it’s own doc here.Performance
Doc performance is all about doc size. Doc size is calculated by adding up the sizes of all doc elements (pages, tables, views, rows, buttons, etc). In docs with huge table counts, its often not the tables themselves that become issues, its the number of rows. If you have 100 tables with 100 rows each, that is the same as having 1 table with 10,000 rows! It’s easy to see how quickly things can add up and eventually, your doc will slow down. Learn more about doc size and performance here.Reducing table count
If you have a doc with too many tables, it’s likely for one of two reasons. 1. You created tables when you should have created views 2. You have an unfocused “mega doc”Scenario 1: Tables that should be views
When discussing tables, it’s helpful to think of your data in terms of nouns and adjectives:- Rows = nouns
- Columns = adjectives
Solution: Combine tables into views. This doc schema is called “One big table”. Here, you create one table for each “noun”, or type of information, and then make filtered views of that parent table for all your individual needs. Because all your views are connected to the same main table, you unlock the ability to run calculations on all the rows, change how you slice things up down the road, and rest easy knowing that if an entry is visible in multiple views, you only need to change it in one view and all the others will automatically update. If you’ve identified tables in your doc that would be better as connected views, follow this guide for instructions on making the transition. Check out the video below or this guide to learn more about this doc schema.
Scenario 2: The unfocused “mega-doc”
If you have a ton of tables that are truly independent of each other and would not work as views, its possible you may have a mega-doc on your hands. A "mega-doc" is a comprehensive doc that serves as a central repository for various topics, often spanning multiple teams or departments. An example of such is a company-wide wiki, where each department has its dedicated section; all the information for running the entire company is organized within a single doc. Similarly, project docs can also adopt the mega-doc setup, containing all the relevant information about every project a department is working on. As content volume grows, mega-docs will not only become hard for users to navigate, but they will eventually hit doc size constraints. In general, it's better to have fewer things in your docs rather than more. This way, users don't have to dig through pages that aren't relevant to them, and your docs can be more focused on specific audiences and situations. Learn more about how to keep docs focused here.Solution: Separate data into more focused docs Typically, docs are created with a specific use case and audience in mind. If different parts of your doc are meant for completely different audiences (for reasons like UX or privacy), it might be a good idea to separate them. If you find yourself constantly making pages that will only be used by a small group of users, it might be worth creating a new doc for them. Check out this guide to learn more about deciding what content goes in what doc. How you slice things up depends on the content of your big doc. Popular options include:
- Team based - Do your big docs have separate team pages or spaces for several different teams? Consider making each of those spaces it’s own team doc.
- Topic based - Does your large doc house information on multiple different projects or subjects? Consider making a separate doc for each.
- Time based - Create a new doc for specific time periods, like a new OKR doc for each quarter.
Rolling out doc updates
While it is advantageous to address risky docs in the long term, altering a widely used doc or process may cause disruptions to daily business operations if not managed properly. If you do decide to make significant alterations to a business-critical doc, check out this guide for tips on how to plan for a seamless and effective migration process.Was this helpful?
YesNo