SQL Database Design Relationship Choices I'd like some advice about how to go about creating a database for the following situation:

I want to track my work hours.
I'll have three entities: Shifts, Category, Location (Example: 6am to 6pm, Nursing, Brisbane Hospital).

I understand the shifts can have one category and one location. So the main question is: Should Category and Location contain a list of shifts? Or I should let the front ent of my app deal with displaying things like &quot;Shifts Per Category&quot; or &quot;Shifts per Location&quot;?
Thank you!
I would personally design it such that there was one more table called ShiftCategoryLocations (or named something a little more user friendly) that had every logical combination of ShiftId, CategoryId, and LocationId. It would also have its own primary key ShiftCategoryLocationId (or whatever name made more sense) so that your WorkHourLog table could reference the 3 dimensions easily by only having a foreign key relationship on ShiftCategoryLocationId. This is known as a dimensions combinations table.
While for small data you could definitely recreate the relations as needed in the application side, but the most efficiency will be if it existed in the database. It also is more reusable and readable in a sense by being refactored into one place, the database.