Skip to content
Kelly's Data Modeling Manual
Kelly's Data Modeling Manual
Common Data Modeling Scenarios
Core Concepts
Glossary
Share
Explore

icon picker
Storing Relationship Data

When you relate two records to each other in Bubble, you have to decide where you’re going to keep that relationship. Let’s look at an example:
Our sample app is a project management app where we have projects and tasks. Each task is related to a project.
We’ve got two tables - one for the projects, and one for the project’s tasks.

So do we do this?
Project Record
Field Name
Field Type
DT/OS
List
Notes
Project Title
​
Tasks
👈
No results from filter
⁠
...or this?
Task Field
Field Name
Field Type
DT/OS
List
Notes
Task Name
​
Project
👈
No results from filter
⁠
...or both?

My rule(s) of thumb on how to decide...

Is this relationship going to change, or is it static?
If it’s static - meaning it will probably never change - I put the relationship on both records. Rationale is:
They won’t need to be maintained (see
@To Maintain
⁠
)
It gives me easy access to the relationship from both records
It makes it easy to view and filter data in my Bubble editor’s data tables
If it might change, I consider how much it might change. If the answer is “infrequent” then I put it on both and set up some logic to update one field if the other changes. This cooooould get expensive in terms of
@Workload Units
⁠
so you have to think about how much this might happen in your app and if it’s worth it.
How frequently am I going to need to access this data?
It’s “cheaper” (in terms of
@Workload Units
⁠
) and usually faster to display a list of things saved on a record (i.e. a Project’s list of Tasks) than to ask Bubble to go search the database for things related to that record (i.e., Do a search for Tasks where Project = This Project). If I’m going to have to run that search on every single page, I might consider putting the list directly onto the Project record.
This doesn’t mean I’m automatically going to do that, though - you can get around the “expense” of running a search multiple times by “pre-fetching” the list on page load via a
@Hidden Variable
⁠
. This way the search is only run once, so the “cost” is very low.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.