Forum Academy Marketplace Showcase Pricing Features

What is the best practice for one-way vs two-way data linking?

I have been reading up on Bubble Database design, specifically how to handle data linking.

The Bubble Manual is a good resource:

But I also came across this awesome resource from AirDev (@vlad / @stephanie):

In a nutshell, they suggest you start off with a one-way link by adding a field to the “subordinate” data type. But if the relationship will be used frequently AND the list will remain relatively small if implemented you can add another field on the “dominate” data type to create a two-way link.

I like this advice because I like simple rules of thumb.

But I’m wondering why they suggest starting with a one-way link on the “subordinate” data type, instead of starting with a one-way link on the “dominate” data type. What is the reason for this?

I find myself having to create a lot of “Do a search for” connections in the editor when the one-way link points from the “subordinate” to the “dominate” data type. Which if I understand correctly, will make the query slower.

I can reverse the direction from “dominate” to “subordinate”, but I’m early on in my database design and I want to make it as using best practice.

So what is the reason why they advise you point from the “subordinate” datatype to the “dominate” datatype?

As the Bubble founders said somewhere, if your Things have a lot of fields, search is cheap, fetch is expensive.


When you say fetch do you mean, for example, “Current Page’s Tags”? And when you say search do you mean, for example "Do a search for” with condition “Tag contains Current Page’s Tag”?

Because if that’s the case, the Bubble manual says the opposite. Search is expensive and fetch is cheap.

No I meant what I said :slight_smile: See this:

Some Bubblers recommended using a separate detail Thing to reduce the data being fetched. For example, User and User-Details, or Post and Post-Details.

Thanks for the link! :slight_smile:

But I don’t understand what you said… which is why I was trying to clarify with examples…

Does the word fetch and search mean something different to my given examples?

How exactly does the idea that “if your Things have a lot of fields, search is cheap, fetch is expensive” effect the way I build my one-way links between my data types?

While the forum post you linked is very informative (I have read and bookmarked) I’m not sure how it applies to designing my database and the direction of one-way links.

Still trying to wrap my head around this all - so I appreciate your help :slight_smile:

1 Like

Sorry, I was getting ahead of myself. I made an assumption (which to be fair does apply to many Bubble apps) that you will eventually loading a Repeating Group (RG) with your Things.

Consider a RG loaded with Things with many one-way links vs an RG loaded with Things with few one-way links. Let’s say the search for both RG’s is the same: all Things created before a certain date. Now, even though the search is the same for both RGs (identical number of records matching the query), the first RG will take longer to load than the first RG --> because the first fetch (transfer of data from DB to RG) is heavier.

Thus, by using inverse linking, you can improve RG load performance, by making Things loaded in RGs leaner.


Ok cool, I think I’m understanding more now…

(Edited out this text because the typo above was fixed)

1 Like

If a data type (Restaurant) has a related data type (Menu Items) and you try to load a RG with all Restaurants, you will be returned all the Menu Items as well, slowing down the load time of the RG.

Something you can do to keep the relation without causing the issue of slow loads is to set an identifying text field on the data type and when you want to relate one data type to another, you can set a text field on the other with the identifier of the first, so it is only a text field and not a data type.

Then when you want to find all the menu items of a restaurant you would do a search for menu items with constraint of restaurant identifier equals this restaurants identifier.


Correct :slight_smile: I’ve edited the answer now.

1 Like

@boston85719 that’s an interesting solution! I’ll have to mull it over.
@deadpoetnsp Thanks for sticking with me. I understand this much better now.

The last thing I’m having trouble with is figuring out which datatype is the “subordinate” one.

Is there a good rule of thumb I can follow for that?

This has to do with how relational databases work:

So, the subordinate in the above example is the order item.

Should you be interested this is a good read > Ultimate Entity Relationship Diagram Tutorial (ER Diagrams)