I’ve been working on my app for a couple of months now and I’m realizing that the database structure may end up being fairly complex down the line. I’m debating between keeping it all within a single app, or breaking the app up into multiple apps, and I’m hoping to get input from somebody with a lot of experience to help make this decision.
The app is essentially a learning management system (LMS) where my company will build online courses for students. The courses have a series of modules, and each module has different content such as videos, text explanations, and review questions.
Each module will also have an “activity,” but each activity is pretty much unique from all other activities within that course, and within all the other courses, so I can’t come up with a good data type for storing the data.
My current approach has been to create the interface for each activity as a separate reusable element, since they have very different types of inputs and steps to complete. Then I have a page called “Activity” and I use custom states to show the appropriate activity, depending which course and module the student is currently on. I save the data for each activity as a unique data type and relate it back to the student.
It’s working fine so far, but I am only about halfway through developing the first course and I already have 27 data types (see screenshot below) because each activity requires different data types to store the data (unless there is a better way to organize it?).
I’m imagining down the road when I have 10 or 20 courses, I’ll have 10-20X the number of data types.
I don’t want to require users to have separate logins to each course, but would it be better to build a separate app for each individual course to store all the activity data, and then just use the main app for user management and authentication? Or is this not as big of an issue as I might think?
Any thoughts from a pro would be greatly appreciated!
Sounds like a job for an “activity” data type AND for an “activity type” data type that you can create as needed and add as a field to an activity. Database structure as follows:
Activity
Title (text)
Type (activity type)
Activity type
Title (text)
Sounds basic but many elaborate apps can be “brought down” to a basic structure.
I have been considering how I could consolidate them into more broad/all-encompassing data types. The issue is that each activity has unique fields (see examples below).
Not a pro, but some thoughts. For each separate app I believe you’d need to pay a separate fee (since Bubble charges on a per-app basis), so I think you’d want to keep it all together.
Thinking out loud, if each activity has a unique data structure and logic/workflows for the user to complete, then I can’t see the purpose of creating a datatype for each individual activity. Only use datatypes for information that repeats according to the same structure.
If each activity is truly unique and requires a unique datatype, then that sort of undermines the purpose of having a datatype. Just build each activity as its own page and create the content and logic there. It’s probably easier to just put it in directly into the page vs build fields that refer to a unique datatype and then have to go into the data tab and put in info there.
(You can create an overall Activity datatype, but it would just hold basic stuff like the name, course it belongs to, ordering, things like that which you’ll probably need for the progression of activities and for connecting courses to students).
Thanks for your reply. I could be missing something but I think the problem with this approach is that part of the activity is having the student who is taking the course fill out the fields themselves. Activities are kind of like special forms with different inputs depending on what the activity is.
For example, one activity is “coming up with a business idea” and the students have to input a list of different ideas. This needs to be saved to the database so they can come back to it later, and so that their instructors can review their work.
Oh, OK I see. I thought this was some sort of pass/fail activity that was automated.
In that case, couldn’t you have a datatype “Answers” and just build a bunch of different generic field types… text, numbers, yes/no etc. Each “answer” entry would have a custom (ie linked field) for User and the Activity. Activity is a stripped down datatype like I explained. Then on each unique activity page, link the answers fields as needed from the selection in your Answers datatype. Then when a student or instructor goes to the page, it will populate for the answers of a specific User.
Hmm, yeah something like that might work. Some activities also have a dynamic number of answer inputs, meaning the student can add as many entries as they want… I suppose those would have to be stored in a separate data type?
And then how do I ensure that each answer maps correctly to a specific input? Like if one activity asks 5 different questions, when they go back to view their work, each answer needs to correspond to a particular question or field on the Activity.
Building on @ed727 thought process and your app requirements @nucleusrobotics . Please consider:
If the only constant thing is change, then build a database model to adapt for that.
Build a “form builder” where you have:
Form
Title (text)
Fields (list of fields)
Field
Title (text)
Type (options set)
Data input 1 for short text (text)
Data input 2 for longer text (text)
Data input 3 for date (date)
Data input 4 for image (image)
Data input 5 for number (number)
Data input … as needed … (types as needed)
Option set
Display (text)
text, number, date, image, etc… <<<
With the above structure then you can create “template forms”. Example:
Template1
Form1 of title “Template1”
Fields (3 texts, 1 date, 3 images, 2 numbers)
Template2
Form2 of title “Template2”
Fields (2texts, 1 date, 4 images, 3 numbers)
Etc. Etc.
So the idea is that you create your templates that you will use to copy when needed to be used in “submission” entries:
Submission
Title (text)
Form (form)
Fields (list of fields from the form template chosen above)
If you want to see something like this in action you can review an mvp I built for quality control audits where I added a form builder. In my app you can create different forms with as many/different fields needed and you can send submissions for the different form templates using a somewhat similar dB structure as suggested above.
Re: mapping, for a specific activity you’d need to hand-link the field. In your Answers datatype you’d have a bunch of text fields (text1, text2, text3) and number fields (number 1, number 2, etc.). For the page for a specific activity, you’d need to hand-link the fields. So let’s say an activity needs 3 text fields, 2 number fields and a yes/no field. For the input for the first field, connect it to text1, and so on. Put all the fields used for a specific activity within a group. Set the group’s data source to do a search for activity where user = x and activity = y. Then the correct data fields will read/write.
And/or, as @cmarchan writes, instead of creating each activity as a page, you can try to semi-automate everything via a form. Beyond his example if you search the forum I recall seeing other posts on people building “builders” for clients. With any sort of automation, the question I always ask is whether this will save me time or cost me time.
On your question of a user adding a bunch of answers that each need their own field… if it’s truly “infinite” and you can’t limit it, then you’d need to build a datatype to hold those sorts of lists where each addition to the list is an entry.
