I am debating what data structure to choose, hopefully you can stimulate my thought process and improve my Bubble knowledge…
Type of users for my web app:
-Teachers
-Parents
-eventually kids but not MVP
The use case is basically, a parent looks for teacher, teacher accepts. The ‘complexity’ is that a parent can be a teacher as well (or a teacher can be a parent)
DATA MODEL1:
Data type User:
-First name - txt
-Last Name - txt -etc all fields relating to an user
-Teacher - User type Teacher
-Parent - User type Parent
Data type teacher: all fields specific to teaching
Data type Parent: all fields specific to parents
basically user is the anchor…
DATA MODEL2:
Data type USER for everything:
-First name - txt
-Last Name - txt -etc all fields relating to an user
-Teacher: Y/N
-Parent: Y/N
then in the repeating group filter by only if teacher is Y
Having done quite a few marketplaces I would personally go with Option 2, although this depends on your use case, whether or not you have a lot of different fields between parents and teachers. Anyways it’s always best to keep things simple and it looks like your Search for Things would be longer if you go with Option 1
What a great question. I would also go with #2 (just having 1 datatype which has fields common to all users, as well as fields specific to teachers and parents).
That said, two things would push me towards #1 (having 3 datatypes: user, teacher and parent, with teacher and parent linked to the user datatype):
a) If the fields related to a teacher or parent got very involved or complex, where it was getting unwieldy to have user hold everything
b) If the way I was showing data would be faster or more efficient with this method
So it may depend on how much you are building out those parent and teacher fields and also how you are manipulating and displaying the data.
I have a somewhat similar thing with a datatype of businesses; right now every kind of business is in there, but this question got me thinking that if I built out certain segments, I may explore whether splitting some of them into their own linked datatype has benefits.
You could just do a User data type with the basics, like email.
Then have one data type for teacher and a second data type for parent.
In your workflows for signing up a teacher or a parent, the user who would be automatically marked as the “creator” of that data type entry is the User who created it, so your user data type would already be connected to a parent or teacher data type created by that user.
Then you have all the necessary data fields for a parent or a teacher on that specific data type.
If you have a user who is going to be both a parent and teacher, you could simply duplicate the data fields that are crossovers of each other, such as name, so that it is on both the parent and the teacher data type, but not the user data type.
Then when you do a search page, your results are not searching a user data type, instead they are searching a teacher data type.
So this is basically your number 1 but it doesn’t have the teacher or parent on the user data type as it is not necessary to make the relation…when you want to pull up the teacher or parent listing easily by referencing the Current user, just do a search for the teacher or parent listing with constraint “creator is current user”
thanks. My question is biased by performance, I don’t care having a huge data type with many records as long as Bubble can fetch Quickly. If relational is faster (option1) then I would choose that option. But I am not sure how Bubble optimizes the db
