DB design

Rather than giving a specific recommendation for this specific case, I’ll give a broader recommendation.

Learn about Database Normalization. Once you learn DB Normalization and have listed out each of the bits of data that need to be tracked, designing the table structure becomes easier.

The first DB I designed took an 8 column CSV file and turned it into a 21 table DB normalized to 3NF.

This video might also prove helpful if you’re wanting to learn more about database design:

Designing Delightful Databases

No worries.

To me , a checklist is an ‘always present’ list of things.

  • Vacuum the floor
  • Change the towels
  • Check the light bulbs

These can have dates or ticks. They can have a person name too. Thats all good
But they are all always visible as options, and you can see if they have been done.

If the row for Towels does not exist in the link table, the list is deficient:

  • Vacuum the floor
  • Check the light bulbs

And you could be forgiven for thinking that the work was complete after entering data against two items.

All I’m saying is that ‘if its in the link table then it happened’ to me implies it might not be in the link table.
I thin it should always be there, and have attributes set or not.
Maybe thats what you meant too.
OP has what he needs, it’s no problem.

[quote=374607:@Roman Varas]@Dave S

I dont’ say it for me, because I am far from pro in this industry, but I understand that thinking needs time, and time is money… So in the equation the budget is a factor to consider when evaluating the quality of the design… (I guess)[/quote]
yes Thinking takes time, and time is money
but the Time invested in a proper design, saves even more time during the build/testing phase

Take time to do it right, so you don’t waste time doing it over

[quote=374613:@Jeff Tullin]All I’m saying is that ‘if its in the link table then it happened’ to me implies it might not be in the link table.
I thin it should always be there, and have attributes set or not.[/quote]

It’s all about flexibility.

If you have a Table with Task_A_Yes-No, Task_B_YesNo, … it’s harder to later add, remove, rename complete categories of Tasks. Yes, you can just add more Columns, but will most probably have to alter your Code in your Website/App too.
But if you use TaskID (and maybe nothing more :slight_smile: ) in your Table, it’s very easy to remove, rename, … all Tasks with ID=x and to add new Task(ID)s. You can even add Code to add,remove,rename,… Task-Categories from within your Website/App for example.

Ahh I see what you mean now.

Not really, its a waste of db space and kind of defeats the whole point of a relational database. If the entry isn’t there the query to return the data that is shown to the user can still show what should have happened and that there is no record of it happening so the end result to the user would be the same. You’d have to insert every cleaner activity into the links table for every room on every day. When would you do that, at 12:01 with an automated system or when the first entry is recorded for that room. Its just loads of extra work that could be accomplished by adding links when they are complete and a nice query to pull the report for that room and day out.

It’s a bit tricky to explain in text.

The whole point (well one of them) to a Relational database is to NOT duplicate data, and to not include “placeholder” data which bloats the database, and requires extra logic to determine if you “care” about the contents of the record.

There should be a table that contains all the POSSIBLE activities with any information that is unique to the activity. This would be a REFERENCE table, and when new activity requirements arise, this table is updated… so it changes very rarely.

Then there is an ACTIVITY table which references the room requirements, this table links to the above Reference table only for those activitys releated to that room. This table has a link to the REF table for all the COMMON information (description etc), and all the information UNIQUE to the status of the activity in relation to the room

Yep.
Thats a good answer

@Roman Varas
Here you go quick overview of db structure :slight_smile:
Can be improved and polished more. This was made in few sec and with right hand.

  1. Stuff
    StuffID
    FirstName
    LastName
    Username
    Password
    Status - is active, not active and etc.

2.Hotels Table
HotelID
Name

  1. Hotel Rooms Table
    RoomID
    HotelID
    Name
    FloorNumber
    InUse

  2. Hotel Activities Table
    HotelID
    ActivityID
    Name
    Description
    InUse

  3. Room Activities Table
    RAID
    RoomID -> Ref. to Hotel Rooms Table
    ActivityID -> Ref. to Hotel Activities Table
    EnteryDateTime As DateTime
    Started As DateTime
    Ended As DateTime
    ActivityMadeByStuffID