Forum Academy Marketplace Showcase Pricing Features

The Ultimate Guide to Bubble Performance - the new edition is out (now 210 pages!)

@petter Hi Petter! i bought the book today and skimmed through it, and it has some interesting topics in it! Great material for the community!
I have a 2 questions about the data structuring section, one about the DB structure and another about the ''Search Data Types" @brian4 also mentioned it before in this post.

  1. Data structure:
    image
    You are using a bidirectional relation, but it seems that when doing a LOOKUP, bubble gets ALL the data from the relation, causing the query to load lots of data. My approach would be to decouple them and only relate the data to the company. When you need to search for thecurrent company data, you just do

search for data WHERE company = this company

  1. Search data types

let’s use a totally hypotetical scenario: A car races website with info of cars and their races (lets suppose each car has only 1 race). My client needs to show certain data in a list (RG).
having the following data structure (Race and car_data are related to car but it’s not bidirectional, if so, if i want only cars, each car would search for all the data inside the related thing)

With the ‘search data type’ you are saying A) to unify the query fields in the main table, or B) to create a NEW table with duplicated fields (that get updated via a backend trigger)

If B is the answer:

Sorry if it’s too long, :sweat_smile:

Thank you again for the great book!

1 Like

Hi @tgmoron

Thanks for the kind words about the book!

  1. Bubble only performs the lookup if needed. If the Thing is not displayed on the page, Bubble will download only its unique ID (which adds about 32 characters extra). So you don’t need to be afraid to connect Things in one or both directions - that adds very little to the overall data load.

I’m not sure I understand your scenario 100% here, but in general there are two reasons to use search data types:

The first is to make a search more performant by setting up a lightweight type in scenarios where the original data type has a high data weight (such as a blog post).

The second is to combine two or more different data types into one search (such as searching for restaurants, hotels, destinations, etc in one search bar on TripAdvisor).

There could be other uses of course, but these are the ones I outline in the book.

how would you create those backend triggers, would i have 1 workflow per field? (when car name changes, when introductory name changes, when race name changes, etc)

Well, a backend trigger will fire even if there’s no condition on it, so technically you can set it up to fire no matter what field is changed, and then simply copy all fields from the original to the search data type every time. There could be plenty of good reasons to set up multiple triggers depending on what they are supposed to do, but it’s not something you’ll need to do every time.

1 Like

Hi, thank you for answering!

That means that for example if i have a CAR table with its data table related:

  • CAR TYPE
  • Car data (relation) [32bytes]
  • Car race (relation) [32bytes]

and a RG that brings the data as: ''Current Car’s > Car data > Country" == Output: Belgium [7 bytes]. Will only load that field’s 7 bytes of data or it’s going to Load all fields in “Car data” and then filter Country? I mean, when getting ‘Country’ key, does it also preload behind courtains every other key data? (for indexing faster later)

Do you have an example workflow of this? maybe an screenshot? is the ‘Search Type’ related to the original things in any way? (if i’m right, i understand that there is a searchType table with 1 search type per item, so if i have 1000 locations and 1000 restaurants, my search type table would have 1000 items in it)

Thanks !

Hey @tgmoron,

Whenever you reference one data point, even if just to get a Unique ID to do a lookup, Bubble downloads the whole thing. So in this case, yes, it will download the full record for Car Type, Car Data and finally the name of the Country. Privacy Rules will of course stop any private fields from showing up.

A couple of points though:

  1. Bubble have hinted that this is probably going to be made more efficient in the future. They haven’t provided a timeline or priority schedule for this, but it’s a move that makes sense.
  2. Keep in mind these are still pretty efficient queries: while I do advocate doing performance optimization, it’s also important to not get too mathematical about it and try to shave off every thousandth of a second you can identify.

That being said, it’s a good thing to be aware of how these choices affect your app. And then decide where you draw the line as to how much you’re willing to invest in optimizing.

Do you have an example workflow of this? maybe an screenshot? is the ‘Search Type’ related to the original things in any way? (if i’m right, i understand that there is a searchType table with 1 search type per item, so if i have 1000 locations and 1000 restaurants, my search type table would have 1000 items in it)

They are related in that they both directly reference each other via Unique ID’s and that they both contain information that’s synced from the “original” to the satellite data type. So If the original is a Car called “Ford Mustang II”, then that name is also saved as " Ford Mustang II" (text) on the satellite data type. So we’re actually storing data in multiple places (which traditional database practices would call a no-no), but the upside is that we don’t need to reference the name of the original when we’re displaying the satellite (like in your previous example).

1 Like