What is the difference between creating a “lists of child type” in the parent table, and creating a field of parent type in the child table?
how do i choose between two options? are there ramifications, such as data integrity, when deleting records in the future, or design ramifications?
Example:
we have two datatypes (tables). One is USERS and the other is EDUCATION. Education is a child for USERS. One user can have two or more schools they attended.
Now difference is when we create a relationship:
Option A:
Create a field in USERS, called Education and set the field type to LIST of EDUCATIONS.
USERS [email (Text), name (Text), education (list of EDUCATIONS)]
EDUCATION [SchoolName (text), from (data) to (date)]
Option B:
Create a field in EDUCATION, called user, and set the type to Users.
USERS [email (Text), name (Text),]
EDUCATION [SchoolName(text), from (data) to (date), user (USERS )] here USERS connection is not a list.
what am i getting wrong here?
i don’t understand the difference. Why are we given two options?
The second one is 1-to-many relationship that i understand is classic.
What is the first one?
Is there even a relatinship?
Basically, in the first one, you already will have all the EDUCATIONS of a USER without the need to perform a Search and filter by the EDUCATIONS that this USER attended. The relationship is here. So, the process to check the EDUCATIONS of a specific USER might be faster doing this way.
In other hand, the USER is a Datatype that you will use a lot around your app. That is, every time you search for a user, Bubble will load this EDUCATION list which, in most cases, you won’t need to. This brings up two problems. One is that your searches will get slightly heavier unnecessarily. And another problem is that we are now charged by the amount of information brought up by Bubble after a search.
So, if “check the EDUCATIONS of a USER” will not be something that you need to do in every Search for a User, I recommend you to stay with the second option
Wow, this helped me progress a bit forward in my understanding.
Does it mean that every time in the user design i perform “Do a search for USERS”, Bubble will load all the connected tables, even if i am not searching for fields in those connected tables?
If it doesn’t, does not load all of it at once, does it make sense to have both connections, just be on a secure side?
If you load a list of Users ALL the data from each of those Users will be loaded (within the confines of any privacy rules) - but NOTHING from connected datatypes will be loaded, unless you reference a field from them.
If it doesn’t, does not load all of it at once, does it make sense to have both connections, just be on a secure side?
Yes, having two-way connections can be a good idea (again it depends on the specifics of your app)…
Sorry, i guess i get it now. Basically, my philosophy should be to stay away from “LISTS of Data Types” as much as possible, right?
Definitely not… lists can be a much faster and less costly way of accessing data - as long as you understand the pros and cons.
As a general rule, small lists (depending on who you ask, some might say up to 30, or even 100 things) will be faster and less costly. Although even lists of 500-1000 things can still be faster and less costly - depending on where and how you plan to load those lists (but can also be way more costly in certain circumstances).
Also bear in mind, you can’t filter a list of things without loading them first, and the ‘find in searches’ privacy restriction doesn’t apply to lists (as you’re not searching for them).
So, again, it really depends on what you’re doing… but there are plenty of advantages to using lists (and just as many disadvantages - depending on the use-case).
Bubble automatically fetches related list values and that data is downloaded and stored in browser’s local storage, so subsequent queries are faster. With the other approach, of doing search, will result in call to the server. It really comes down to the design choice and what you are trying to accomplish. In my option, if the related lists are small use the first option, and if there are many many row then there’s no need to download all that data user may or may not interact with.
Hope this makes sense
As @adamhholmes said, NO. For what I know, the only thing that will be loaded is the Unique ID of these elements. That is why I don’t see any reason to create a list inside your USER if the things in these lists will not be used in every search. What I said was regarding create lists inside USERS.
…the USER is a Datatype that you will use a lot around your app. That is, every time you search for a user, Bubble will load this EDUCATION list which, in most cases, you won’t need to.
In my Apps, for example, the datatype USERs have only a fill fields such e-mail, name, access level and banned (yes/no). All other fields such address, zip code, phone, documents, photo… are saved in another datatype as I don’t need to see the phone of the user in every search… i don’t need to see his photo in everysearch… and etc…
I know it might sound extreme. But if you have expectations of having thousands of users doing thousands of interactions, it makes difference in the end…
