Apr 24, 2020 02:48 PM
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?
Solved! Go to Solution.
Apr 24, 2020 03:23 PM
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.
Apr 24, 2020 03:23 PM
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.