I’ve built an app that tracks training hours and signatures for a fire department.
Background: I work as a firefighter - we train everyday and fill out paper forms where each attendee signs the roster, the roster is later input into an online system and the physical copy is filed away. I created a system that will do this all in one go. When the training coordinator creates the training on the app, it will send an email to each attendee, who will log in and sign on their phone, this tracks all the hours and type of training along with the signatures.
It works well currently. However, I’m concerned about launching it because of how I built it.
Currently, when a person signs a training sheet it creates a new line of data with that persons signature. So if 10 people do a training, it will have 10 seperate lines of data. For a small department who has 25 people training every day, by the end of the year there would be over 9,000 lines of data/signatures in the system. I’m worried this will quickly become bogged down, especially if I add additional departments in the future.
I considered/tried creating a workflow that will create a PDF of the training sheet once it’s complete, and then delete the cooresponding signatures, therefor each training would only have 1 image/data item instead of multiple, but i can’t get the PDF function to work cleanly.
I tried creating it so that all the signatures would be in a list on a single line of data, but I can’t get the signaures and the names to line up. (If person A is the first on the list but signs the sheet 5th, their signature is next to the person who’s 5th on the list).
I’m open to any feedback. Let me know what you think.
I have plenty of tables with 100s of thousands of records and it all works flawlessly.
Having a lot of records can only slow loading time if you want to show items in a dashboard but then you will have some sort o date range for which results are shown anyway. You don’t have to check if a paper was signed 2 years ago every day.
I thought your idea was really cool. I’m just going to talk about one thing here: in your method, if I understand correctly, will the person who is going to train register this? You said that there are 25 people, if they all go every day, these registrations will be made every day. Or else, as I went through a help where we made a model of a garage where there are identical cars and they have lights, brakes, etc., but when you enter you only enter the name of the car and update the record of the car’s items, like in the case of firefighters, it could be the person John, who climbed the stairs today, but tomorrow the same John did another exercise, I don’t know with a fire extinguisher, but his name will be on the table once, and his training items will be included with different dates, or in this traditional way, of entering one by one per line without any problems. My vision, I don’t know if it’s along those lines. Thanks.
Images have WAY more weight than text entries in the database, so they’ll bog down your app a lot more, but still it wouldn’t be that big of an issue. Our main app page typically has at least 20 “searches” on the page that search through ~1.5 million records. These searches still complete really fast and it hasn’t been an issue for load times, as all the data gets loaded in 1-3 seconds, depending on internet speed.
I wouldn’t worry too much about future data issues… you can always restructure and solve those later on and generally you can’t predict what will be the biggest issues or WU users until people actually use your app.
There are lots of ways to reduce searches and WU usage on a page. For example I have a page with a list of events and the event data type is quite heavy (was built before WU was an issue) - to get around the heaviness without a big rebuild I just group the events by status and then do a count per status, then the user can click to open specific status and each does a separate search. Most of the data is in the “completed” status so it rarely gets returned to the page because that drawer is rarely opened and the other drawers only have <100 events in them so very fast to download.
When I built it initially I noticed significant lag and that’s because I was counting the repeating groups within the drawers - this forced all the searches to run on page load just to get the counts. I changed it to do separate aggregate searches and that stopped the data from being fetched. Bubble has a lot of little quirks like this but you can figure those out when you optimize after launch.
@christianszadyr I must say this is a really brilliant foresight.
However, I never thought about @samnichols idea which is also very brilliant. And if you were to take that into consideration I don’t think there would be any need for the PDF implementation that would even take more processing power and use up more space in your db.
Thank you everyone for your responses, you’ve all definitely helped ease my mind. I did think of a work around after asking this questions : Where i’ll have the user sign their name one time and save it to their profile, and then whenever they “sign” another training sheet, it will just input their pre-saved signature, that way it should have even less demand on the system searching through records etc.
For a bit more piece of mind. What you basically did is normalization. Which is very smart. It gives you flexibility and performance.
Remember that Bubble use Postgres as a database and Postgres has no issue whatsoever to hold billions or rows and thousands of tables with in each table hundreds of columns.
What could happen is that Bubble will charge a lot in the end when you have lots and lots of data flowing in your app and users. But if that happens and you have normalized your data you can always off load the data to an external service like Supabase for instance.
There’s a signature pad plugin I’ve used for this, and it will create a very lightweight image of the saved signature that you can store in the db for use later. Works like a charm.
