WU consumption - Current user's data or Data's contains Current User?

[heitordeap]

Hey everyone!

Deciding on which architecture to use on my DBs. In my use case, most of the data stored are linked to an user (current user) - as probably most apps around. Hence, I created several different databases (types of data) and the decision is around how to link them together:

A) to create a field “user” and include the current user in each thing in all databases. That means that the search for a specific thing would be: Do a Search for Thing filtered > Thing’s User = Current User and another filter that returns the specific thing.

B) to create a field in the current user with the Thing Type as a List. Any time a thing is created/deleted, it is added/removed from to that Current User’s list of Things. That means that the search for a specific thing would be: Current User’s List of Things filtered > to the filter that returns the specific thing

Both of them work, the paths they do for the search seem very different. Does anyone know which one would be more efficient in terms of WU? Or how to evaluate that?

Thanks!!

[net-tt]

Check out this post.

One-to-many-to-many-to-many performance

Let’s be nice, please If A has a list of B, whenever you load A, you load all the ids of Bs in that list. We may change this eventually but no short-term plans to do this. We don’t actually load the rest of the data for the Bs unless you actually reference a property on the Bs. (I think! If you can build a simple test page that demonstrates otherwise, submit it as a bug) If you’re expecting to have a list > 100 items, I always recommend establishing the relationship in the other dire…

[nico.dicagno]

There isn’t an universally right/wrong answer; it depends on your particular use-case.
(Although I will say that most of the time option A is the best, especially in Bubble, as using lists is not as versatile as using a reference to a parent)

The options are usually named the following.
Option A: Parent reference on child
Option B: List of Children on Parent
There is also Option C: use both. This is called a bidirectional relationship, and it can be useful in many scenarios.
There are other options but they are much obscure/advanced.

There are many forum posts which discuss something similar to this. I would recommend reading as many topics as you can bear. The more you read, the more you will understand what differentiates the different use-cases, as well as why the optimal solutions work well. With this knowledge you’ll be better able to analyse your use-case and what the best solution is.
I also really recommend @petter books on Bubble Performance & Security.

There are many factors to balance. Its not only WU, but also speed, scalability, how easy it is to change/add new features, privacy, etc…

The being said here are the most basic rules of thumb i can think of :

How many data-entries at most do you expect a user will create?
Lists are great with a small number of entries, and can save you from doing an additional search. However if the lists get too long, performance starts degrading real quick. Never use lists of more than 1,000 entries (this figure is heavily debatable, there is no one precise figure. The hard cap on number of entries is currently 10,000, however there aren’t many use-cases where lists this long make sense on Bubble). If you know that the list of things is under 10 entries, lists are a great option, but there are other considerations…

How often do you need to retrieve the data?
Does your user need the data on every page load? Lists can be useful here.
If your user needs this data more rarely/sporadically, locking it behind a search can save WUs and increase page load.

How ‘heavy’ are the data entries?
‘Heavy’ data entries generally make it a better option to use a parent reference rather than a list. The reason for this is that if any of their data is referenced on the page, lists are downloaded in their entirety, which costs WU and slows down the page. Searches benefit from lazy loading, and bubble can load them progressively as they are needed.

Should other users be able to see some of the user’s data entries but not all of it?
Privacy rules do not apply on lists. If a user is allowed to view the list field of another user, they will be able to view the entirety of the list, reardldess of whether you only wanted to let them access a few entries. Using a parent reference on the child allows for better application of privacy rules and allows you to show only a subset of the list

[heitordeap]

Thank you both for your replies! Very useful. In my case, scale is not really a problem, lists could work fine, but the privacy rules and the frequency to load that data encouraged me to go with A - Parent referenced on child for most cases.

Just out of curiosity, in which scenario a bidirectional relationship could be useful?