How does bubble's DB actually function with list fields

[d.pearce]

Hi,
I am just looking for some insight into how bubble deal with List fields, so I can understand how it might impact on speed.

If I have a list field in my DB, and my form is based on that table. Does bubble load the data in and run queries irrespective of whether I have that displayed on the form, or are the queries only done when I actually display that data.

Additionally, how does that work with self joins.

I have seen a couple of very slow solutions, one with 19 list fields in the user table, and I am suspicious that the time to load of the page is being affected by this fact, even though the solution has very little data in it?

It would be useful to have some insight into what Bubbles engine is doing in the background, so we can structure the DB to improve speed.

Thanks

[cmarchan]

Hello @d.pearce

Alternative approach to the Bubble’s recent tutorials for list of things

Hello everybody, I’ve taken a look at some tutorials from the following topic: In short, I think that these tutorials contain some crucial mistakes. Regarding How To Build A Pinterest Clone Without Code Configure your database User [image] We’re facing this mistake on many apps. That’s a wrong approach since it negatively affects performance and speed. Let me explain why I do think that this is wrong. The Bubble’s unique id for each thing looks like the next one: 1583401182457x36677…

The Ultimate Guide to Bubble Performance - 156 pages of optimizing tips

Hey everyone, I’m very happy to announce that I’m releasing my book The Ultimate Guide to Bubble Performance today. [image] It’s a 156 page PDF available on Gumroad that dives deeply into the hard-earned lessons I’ve learned over five years of full-time Bubbling, focusing on: how to determine whether Bubble is the right tool for your project: the pros, cons and limitations from a performance perspective how to set up your app to load pages, process workflows and edit database records at ma…

Performance Q&A guide

So some overall guidelines. Note that these kinds of guidelines definitely have a sell-by date, since we’re always trying to optimize slow stuff, but here are some of the big performance levers: The more data a search fetches, the longer it takes. That probably sounds pretty basic, but we routinely see pages that fetch thousands of data items on page load. Or, we sometimes see searches that only fetch a few things – but each thing has KBs or MBs of text data stored in its field. Bubble …

RG vs "Search for" (performance questions)

@rpetribu The conventional wisdom after much time learning from knowledgeable folks in this forum (my understanding of it). And through my own experience building apps is to: build light objects minimize list fields (only when less than 100 entries), only use them purposefully relate objects indirectly but both ways when necessary preload searches feed from preloaded searches avoid inflow searches (… hence preloading them) mnimize back and forths between client and server use custom events ex…

What are your best tips for designing fast apps?

This is my method as well. Always assign to the first parent that might need it. It allows me to copy/paste with workflows across apps pretty well.

[d.pearce]

Thanks All,

I am seeing a lot of solutions where I think “List Fields” are misused.

i.e in the convention CRM you have:

Companies and Orders.

So I would always use a foreign key in the orders table and link idcompanies to fk_idcompanies.
I see people in Bubble using a list field in the Companies table.

List of Orders

I cant help think that that is very wrong as the List field will be an object that is not indexed.

Also if you have s subsidiary table used by multiple companies, then I would expect to use a:
companies_to_orders table with simply an fk_idcompanies and and a fk_idorders field.

I assume the are indexed and traditional relationships when i define them a fields from the other tables.

I can see for a post which might have 20 likes, how the list field could work well, as all I want to do is count the users who like, but I fear it is dangerous relating in this way when I might want data or to sort the data in a repeating group at some later date, as this is an object??? (is it!) relating to the secondary table.

I think the answer that says dont use list fields if you have more than 100 things in it, appears to confirm my suspicions.

Thanks