I’m trying to use Bubble.io to create a ticket-selling app for a train. There are several layers of data objects that need to happen for this and I’ve finally thought of an approach that will be easy. My lowest level of data is a “seat” on a train. Now my first issue presents itself which is assigned seating because each seat is not the “same” and I need to display whether a certain seat has been taken on a given train. I create a series of dropdown inputs arranged in a 5 x 14 grid to represent the train layout. I couldn’t figure out a better way to do this than creating a data object “seat” which will have a unique seat name. I’ll bind this onto my train layout dropdowns and then add individual “seat” data objects as fields in my “platform” which is just a given train. Now the problem as you see probably see is I’m adding 70 “seat” data objects to my “platform” object. I can have up to 3 platforms per hour if the train is busy (210 seats) and up to 9 different trips throughout the day (1890 seats). Last year we sold about 150,000 tickets and we’re anticipating at least the same if not more yearly. Can bubbly.io handle 150,000 new entries in a table per year or is there a better way to structure this seating data so it doesn’t get out of hand?
There’s no database limits for the amount of “rows”. I think if you did a search for something it starts to slow down as you search for 50,000+ things.
The concept doesn’t sound too hard in Bubble. Like you said though you might have to figure out the best way to go about storing the data.
Do you care about the “history” of a seat? Like when someone is assigned, are you storing a user or person’s name for that seat. or are you simply checking a box saying it’s taken? If this is a user-facing app would you have logged in users that could claim a seat and they would be able to pull up the seat number they reserved? All of that sounds like it’s do-able.
I’m also trying to figure out the best way to store “seats” for reporting. Ideally, I’ll add a “Customer” object which will be linked to the “seat”. A list of seats purchased at one time would be an “order” and that would be added to a list of “orders” which constitutes an order history for the customer. The primary goal of the user facing experience is to reserve/pay for seats with confirmation email, unique barcode for each ticket, and potentially an area where they could download tickets as images to their phone after they login but that’s a future idea. I think just due to the amount of historical data from another application, I’ll probably try to figure out some way to export this data to MYSQL and run reporting off of that server.
