Help

Discover what data silos are costing your org in our commissioned Forrester study. Learn more

How many tabs (tables) are too many? (Deciding where to put data)

Solved
Jump to Solution
1175 1
cancel
Showing results for 
Search instead for 
Did you mean: 

How many tabs on the top is “too many”? How do you work out what to add to a table and what to bring to a different table.

For example, I am tracking clients and behaviors. I want to create customized behavior goals and bill for their services (and eventually other things).

Right now I have:

Table 1: Client Information (names of kids)
Table 2: Contact Information (parents, foster providers, case workers, team members of the kids, linked to their kid)
Table 3: Notes that I write about each visit
Table 4: My invoices (linking to the start/end day and time, duration generated in Table 3)
Table 5: Goals, behavior tracking

I guess my question is should table 5 be on it’s own, or should this be consolidated in “client information”? What is the benefit of having Table 5 house behavior tracking (linked to Table 1) vs. having a separate view in Table 1?

1 Solution

Accepted Solutions

Here’s a related article on base structure. Relational database design is a big topic. Related posts on this forum generally have the tag “base design.”

Not sure what the upper limit is on the number of tables in a base is. But I generally try to keep it so they all fit on one screen. I aim for the (1) fewest tables possible while still accurately representing the data (2) as little data duplication as possible (3) each row of a table should be a unique thing of a larger list (ex. a specific product in a table of products).

If you’re billing per visit, you might be able to get away with just two tables: Clients and Visits. Visits would contain any information about the visit and billing details. Each row would also be linked to a given client. That way when you need to do behavior tracking, you can aggregate data from each visit.

See Solution in Thread

1 Reply 1

Here’s a related article on base structure. Relational database design is a big topic. Related posts on this forum generally have the tag “base design.”

Not sure what the upper limit is on the number of tables in a base is. But I generally try to keep it so they all fit on one screen. I aim for the (1) fewest tables possible while still accurately representing the data (2) as little data duplication as possible (3) each row of a table should be a unique thing of a larger list (ex. a specific product in a table of products).

If you’re billing per visit, you might be able to get away with just two tables: Clients and Visits. Visits would contain any information about the visit and billing details. Each row would also be linked to a given client. That way when you need to do behavior tracking, you can aggregate data from each visit.