I’m new to bubble, and even though i’ve been searching around, and i can’t seem to find a good answer for this: I’m at point in my app where i have many data types (each with many fields), and i have many of these types linking back and forth to each other (both ways), so it looks something like this:
Company
- name = TEXT
- logo = PICTURE
- employees = “Users”
- address = ADDRESS
- local health departments = LIST (“Health Departments”)
- customers = “Customers”
- sites = “Sites”
Users
- name = TEXT
- admin access = YES/NO
- company = “Company”
- email = EMAIL
Health Departments
- name = TEXT
- city = TEXT
- address = ADDRESS
- inspections req. per year = NUMBER
Customers
- name = TEXT
- phone = TEXT
- address = ADDRESS
- site = “Site”
- C-owner = “Company”
Sites
- name = TEXT
- phone = TEXT
- address = ADDRESS
- S-owner = “Customer”
- Co-Owner = “Company”
- Auth = “Health Departments”
As you can see, many data types are cross-linked, i understand this can be helpful, but is there a point (maybe two or three types ago) that it starts causing errors or some kind of significant server usage where i’d want to re-think this?
Would i be more effective to “do a search for” and input some constraints in certain places to limit the number of cross-links? or is it more efficient to use cross-linking if it means one less “do a search” is used?
what are the potential downsides (if any) to having several cross-linked data types? and if there are downsides, what’s a reasonable number of cross-links to target in order to keep my app as light as possible?
Shame this didn’t get a response. I’m also wondering the same.
I just finished studying this resource: https://manual.bubble.io/working-with-data/connecting-types-with-each-other
My take away is that cross-linking is good for fast database responses, but you have to explicitly update both fields because updating the link in one direction does not automatically update it the other way. If you forget to update both it can cause data inconsistencies, which has already caught me out once.
I have also found this resource: https://docs.airdev.co/canvas/using-bubble/bubble-best-practices/database#privacy-rules
They suggest starting with only linking the “subordinate” data type, and then if the relationship be used frequently AND will the list remain relatively small if implemented you should has a two-way link.
Good Links there… I’ll read up. in the meantime, I’ve re-structured my database in an efficient way as possible… which it appears that bubble article agrees with and it seems to be working out thus far. 
Hi @thecashbag and @tayloryouno,
To complement those great links consider watching this video Data architecture design in Bubble.is made by channel NoLogo in YT.
Also, @josh (Bubble co-founder) guiding comments in a fair and honest chat about performance
In essence, my experience has been bulding indirect links when linked data is large. And direct links when data is small (less than a 100). When the build is all-around done for performance (avoiding excessive searching, filtering, long page loads, unneeded dB calcs, modular flows with adequete custom events, reusable elements, among others) searching work well, And lately, Bubble has felt pretty fast from where it was a few years ago I may add.
Hope this helps!
1 Like
That video was great! A bit advanced for people starting out, but great if you’ve been reading up on this stuff like I have. Helped me picture it all clearly now.
And I also concur that the performance Q and A is great for people digging into this stuff.
In summary: Inverse linking is probably best to future proof your app.
1 Like
That is the same main point I drew! 
My apps are going much faster after I implemented this dB approach
I’m trying to map out the data architecture of a fairly complex SaaS app in excel at the moment. Wanted to get it planned out before I dive in.
But I’m having trouble sometimes figuring out when which data type is “subordinate” to another. This makes it hard to do the inverse linking, which is counter intuitive at the best of times.
Do you know a good rule of thumb for figure it out which data type is “subordinate” to another?
When a superordinate is useful
