Hi All - I’m completely new to Bubble and just learning my way around, so (i) apologies if my questions are super basic and (ii) hopefully I’ll be able to give some help as well as receive as I get further up the curve.
As an exercise to help me learn, I’m building a simple scheduling tool where a user can see a schedule of events and join those events by booking in. In a couple days I’ve already created the list of events and created a simple booking structure where a DB recognizes an unique event. Now I’m trying to add a user to that event by creating an “AttendanceList” field in that event and adding a current user to it in a series of events that happen after a button is pressed.
My issue is that I’m struggling a bit with the structure of that field. When I set it up as a normal field, I’m not sure I can add multiple distinct entries to it. When I set it up as a “List” (with multiple entries), it requires me to add something to the list to save the entry. Happy to share the project with anyone who’s interested, but a little help in understanding how to structure this would be super helpful.
Thanks in advance - psyched about getting up the curve here!
I don’t really think that it is the easiest way to sort events or users but I might be missing something. For instance with your last example you’ll have to create another list whereas with one new table (bookings for instance) you can do both with only one table.
Moreover, it seems to be more obvious to have this new table in terms of evolution capabilities because you might want to add things like has the user have paid, has he attended the event,…
Yes, I agree that creating a “Booking” thing is the next step.
Booking is a combination of user + event + some data but you can always save event+somedata on the user and have much the effect that should be a bit easier to navigate. Otherwise you often end up doing lots of searches for stuff.
But it is a tradeoff between readabilty of your data (because you have two lists now) and ease of searching (because the list is right there in your thing so you have the list to do operations on).
So even at its simplest, a list of bookings, it is more complex to search the booking table for bookings where they match this user… than it is to show the list on the user. And once you add requirements to filter etc. …
But that is just my preference, make my queries simple (as I do them a lot) rather than make my data set up simple (which I do infrequently). YMMV.
Thanks so much for your help Nicolas & Nigel. I’m just coming back to this now and will definitely use multiple tables for this. I’m new to relational databases, so in some ways I guess that helps to prove the conept that this product is pushing the boundaries of programming further out into layman’s land! Your help guided me to a couple Lynda courses on DB structure and with a little work I should be in good shape.
Loving the product so far and it’s awesome to have such a helpful community. Thanks again!
