I have a Sessions table that is showing this single Group Session where I have 4 Clients who want to take part each paying £5 creating a group total of £20.
At the bottom I have a list of the 4 Clients but I would like to be able to check whether they have paid for the session or not but I’m struggling.
So the Paid boolean is located within the Session but obviously there is only 1 checkbox for the single session - is there a way to break this down into 4 individual checkboxes (or more should more clients join…) where I can check them as Paid or Not.
The problem I’m having I think is that the 4 clients aren’t individual records within the Session, they are within a split text column created from a choice component.
How would I add individual boolean switches to these records to switch them to Paid?
If that number can be dynamic, I would seriously consider normalizing your data structure. You are creating a one-to-many situation, without knowing if you can have 1, 2, 3, 4, or more clients per session. Problem is you are trying to do one-to-many in one row.
You could go down a path of having a temp table to blow out those comma delimited clients into individual rows, add additional columns in the temp table for additional info you want to aquire for each client, and then build a JSON string merging it into one text value that can then be written to a column in the session row. It’s possible, but a lot of extra work in my opinion. Then there is the whole process of unpacking and repacking that JSON every time you want to change a value within it.
You may just want a checkbox in addition to client now, but in the future you may additional information for each client. A separate session-client table with a row for each client per session, is going to be a whole lot easier to maintain.
If on the other hand you know the absolute max number of clients you could ever have for a session, then you could create individual columns for each client in the session table and choose each client individually instead of using a multi-choice component. It’s not good database normalization, but it keeps it all in a single row while not being as complicated as building JSON that needs to be packed and unpacked.
