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?
You can nest objects. For example, you can have the following tables:
User (teachers or students or both)
Then a user can have a field called ‘Classes’ which is a list of ‘Class’. That way for each user you can add classes.
A user can also have a filed called ‘Assessments’ which is a list of ‘Assesment’. So for each user, you can create and then add assessments.
Assesment can have a field called ‘Class’ which is a single ‘Class’. So you can store which class an Assesment is associated with.
Yes, I’ve got that setup already.
i.e a seperate table for:
assessment_details (lists of above)
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?
Are you having performance issues already ?
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).
I’m sure I read there was a 10000 row limit! Okay, well that solves that. Many thanks.
Ah, yes, there is a 10,000 limit on items in a list, but not the number of rows in a table.
So if you had a Teacher User, and you had a list of their Assessments … then that might well break the limit.
However you are unlikely to do that, you would have a List of Classes, which had a list of Students, each with a list of Assessments.
Ah, items in a list, got it, not rows.
That’s fine, unless the poor kid gets assessed to death it will be fine! Thanks again.