I am bulding a booking system where the users will be loading available time-slots in the browser to select.
Each of these timeslots needs to have a reference to all the bookings that have selected it (for some custom capacity calculations). Today I have these bookings added as a list on the TimeSlot object.
Each timeslot can likely have a list of 40-70 bookings, and when the user loads the calendar it will likely load 150-200 timeslots.
With only a few bookings in the system there is no performance issue. But I have a hypothesis that this will become painful since the browser indirectly will load references to 10k+ bookings (70 x 200). Can anyone with knowledge to DB structure confirm this assumption?
If so, is it any way to keep the logic as this, but not load the booking references (other than privacy rules)
One potential workaround that I’ve considered is to have an object between the two, that contains the list of bookings.
Do you have another datatype currently called Event or something they are actually making the booking for? (the thing that would contain the address/name/etc)
Make a datatype called Booking and it will have a field for Event and another field Timeslot. (not list fields just regular fields) Then you can have a User field on this if a specific user needs to be tied to this.
Then to get all Timeslots for a given Event you would do Search for Booking with the constraint Event = [the one you want] then after the search :each item's Timeslot
Or if you need all Events for a given Timeslot you do Search for Booking with the constraint Timeslot = [the one you want] then after the search` :each item’s Event
Yeah, there is one datatype called Booking, that is the unique booking, this is what is referred to in the list.
I’ve deliberately chosen a list over the “Do a search for” action under the assumption that it will be server intensive. Each TimeSlot will need to recalculate the requested capacity (from bookings) maaaany times per day and there are many slots. So if each event triggers a DB search I fear it will require to much. The idea was that having a list would simply allow me to sum up the content of the list instead of a search. Or am I wrong?
The list fields are going to kill your client side performance as you’ve seen so the only way to cure that is switch to server-side searches. Searches don’t take as much as capacity as you would think and are lightning fast.
The only way to do the search though is add that third datatype I mentioned (sounds like you already having Booking so rename either one) containing a single Timeslot and a single Booking.
You mentioned having an object between the two with the list field but your client’s browser is going to come to a screeching halt again when it needs to download a huge list VS the server doing the heavy lifting then providing a much smaller list.
Plus your list fields, aren’t they longer than whatever search results would give because you need to do :filtered after it to get only certain ones?
And you could use the Data API and make a ton of dummy data and have some recalculate workflows running in a loop X amount of hours apart and see what your capacity looks likes VS the list fields. I would imagine they wouldn’t be much different
