Help

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

Solved
Jump to Solution
2301 1
cancel
Showing results for 
Search instead for 
Did you mean: 
Nate_Sheets
6 - Interface Innovator
6 - Interface Innovator

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
Zollie
10 - Mercury
10 - Mercury

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
Zollie
10 - Mercury
10 - Mercury

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.