So I’m creating an app to do with assessments within a classroom.
The app will allow me to assess the students whilst their learning, by adding assessments to their username during a lesson. (mini-Moodle functionality basically)
I think that my “assessments” table will reach 10000 rows fairly quickly under the current design (i.e 15 classes, x 10 or 15 assessments per student per project per year)
If I were to make this app available to other teachers it would fill up even quicker. What process would you use to break up the tables for different teachers or even different schools.
I can’t see any “dynamic table creation” functionality for example to create an assessment table for each class or teacher.
Is it simply that it will require API calls to an external hosted table?
Yes, I’ve got that setup already.
i.e a seperate table for:
student
class assessment
topic_grade
topic
topic_assessment_criteria
assessment_details (lists of above)
etc
But my problem will still arise from the shear number of times the “Assess Student” button will be pressed!
I’m guessing I’m just hitting a performance barrier in Bubble?
I would suggest that they are far more likely to be due to your database setup, or your queries, than anything Bubble is doing.
Solve that first, then look at doing more complex things.
Bubble data access at large volume is pretty quick, as long as you are using “apostrophe language” so navigating via bubble’s field links.
Where it does slow down (and it would do this if you were on mySQL too) is when you are searches within searches on large tables. So you search through a table, and for each row you then need to go and search through the whole of another table to find something. That is when 100,000 x 100,000 really starts to bite.
Have you tried using a repeating group instead of a table? You could then filter assessments with a searchbox or with an input and display in the RG only the assessments containing the field you choose (teacher, teacher name, student, etc). You find the “any field” function at the bottom when you “do a search for”, so you will display only the assessments that contain that field
Further, if teachers don’t need to access to other teachers’ assessments, you could keep them separeted by making them create their own account, so that each teacher will only access to their own assessments
I think I’ve been too inaccurate with my terminology.
When I said tables I meant Data types in Bubble *(I picture them as tables as I’m an MS Access kid!).
All the data types are “nested” or what I consider one-one or one-many relationships etc.
By “performance barrier” I should have said something like “a built in limit of Bubble”.
I’m still making the app so its not live, but I’m anticipating the 10000 rows of my “assessments” data type to fill up quickly. Is this not a common problem? Or am I misunderstanding something.
Not really a problem. Large amounts of data can cause issues with maintenance, so if you need to upload 25,000 records from a csv, or update all the rows to link to another table …
But in general, having a lot of rows should not be an issue. I have apps with that amount of data, and don’t really have a problem (beyond the data update/upload).
