Save the date! Join us on October 16 for our Product Ops launch event. Register here.
Feb 22, 2024 03:56 PM
For my small business, I have three levels of information I'm trying to manage. I have (a) the human client, (b) their pet, and (c) the services that they want for their pet. Each human can have multiple pets, and each pet can have multiple services. The projects themselves occur at the pet level, since one human might come back multiple times with different pets, and all the services for a pet occur at once. A pet will not come back for more services again in the future, so it makes sense that we could consider "pet" to be the main unit of analysis (sorry, I'm a social scientist by training, forgive my lingo). A big part of my work is thinking about how I complete tasks by what services I need to do in any given day; in other words, Spot might need Service A, Service B, and Service C done, and I care about knowing what services I've already done and what I still need to do for Spot. Although Service A is always "Service A" for every pet, the price for Service A changes depending on the pet (for example, Service A will cost more for a heavier dog).
I'm struggling to figure out what my tables should look like. I have "humans" and "pets" tables, which makes sense. When it comes to services however, since the services are occurring at the pet level...what's the primary field for the "services" table? Any other overarching guidance on what these tables could look like?
Solved! Go to Solution.
Feb 22, 2024 04:50 PM
If I were you I'd have a standalone "Services" table that just listed all of the available services, and a fourth table called "Services <> Pets" or something, which would have a linked field to both "Services" and "Pets". Each record in this table would represent a single service for a single pet
I'm assuming in the "Pets" table you have a field that denotes the size / weight of the dog or something? If so, I would put the different rates in "Services" as well, and then pull that data over into "Services <> Pets" via lookup fields, as well as the size/weight from the "Pets" table. This would allow me to create a formula field that would give me the rate for that service based on the linked Pet record
The primary field for this new table could be anything, really, and I probably would have a formula field that showed the data of pet name, service name, and perhaps date. Doesn't really matter unless you need it to be in a specific format for linking to another table or you have users filling out forms and such
Feb 22, 2024 04:50 PM
If I were you I'd have a standalone "Services" table that just listed all of the available services, and a fourth table called "Services <> Pets" or something, which would have a linked field to both "Services" and "Pets". Each record in this table would represent a single service for a single pet
I'm assuming in the "Pets" table you have a field that denotes the size / weight of the dog or something? If so, I would put the different rates in "Services" as well, and then pull that data over into "Services <> Pets" via lookup fields, as well as the size/weight from the "Pets" table. This would allow me to create a formula field that would give me the rate for that service based on the linked Pet record
The primary field for this new table could be anything, really, and I probably would have a formula field that showed the data of pet name, service name, and perhaps date. Doesn't really matter unless you need it to be in a specific format for linking to another table or you have users filling out forms and such