I’m looking for some feedback for efficient data structures and best practices of attaching a list.of things to a parent thing.
I am working.on a lesson builder, where a teacher can add a series of artifacts and links to a list of resources that are assigned to a lesson.
My question is, for scaling and speed purposes-
Is it better to have one database with all of the lesson components, or have a database for the lesson and a database for resources- where the number of resources are linked to the lesson?
Also, how would I set up a connection from the lesson database to access the “resources” database so that the resources would populate in the repeating group within the lesson and that I can add/modify/delete the resources from the list.
I did. And, I do understand the basic premise of “things” discussed in the tutorials in the bubble video
I guess my question is coming from the idea that on my page, I am going to have a lot of information that is dependent on other things- and as I build out each of these, it is going to get more and more info making each layer more and more complex- as each resources will have separate things, including name, link, description…and each lesson will have a number of resources, questions, tutorials, name, description… And each app will have a number of lessons and assessments as well as a. Name, description, tags, etc. I can see it getting very large and very data intensive very quickly.
I also know that speed, with bubble, is an issue. I am trying to figure out the best way to structure it early on in order to make it efficient as it grows in both ability and users all while making other functions of the CRUD function as quickly as possible.
In my head, and I could be wrong- this means possibly having 25 or 30 (or more) smaller databases that focus on one particular microcomponent and then linking them all together, but before going that route- hoping to hear from others who have structured data heavy apps and can provide some insight
Sticking everything in a single table is not going to be efficient, but then neither is splitting out each and every little thing. And by efficient, I don’t mean access time, I mean in searching and counting and filtering.
I would say 30 tables … is a pretty complex app. You probably don’t want to split out names and descriptions intoi separate tables.
One way of working out if something is a discrete “thing” is try to uniquely identify it. “Is this something I could look up in a paper list ?”
Lessons, resources, staff, questions … all seem like “things” that you can name, or at least give an id to. “Lesson 3” or “Question 45”, “Frank the metalwork teacher”.
Then build up your tables based on attributes of those things. And link the tables together using the concepts in the tutorial. So having a list of something on another table.
Where bubble (or indeed any database) gets slow, is when you end up having to scan an entire table multiple times to get a result. So if you want to list out the lessons for teachers - if you scan down the teacher table, and then go and scan the entire lesson table to find out which one is for this teacher and then move to the next teacher and scan the entire table … etc. That will take a long time. If the answer is on the teacher table … so a list of lessons, it will be much quicker.
I have some fairly large databases, tens of thousands of rows. And some fairly complex ones.
