Hello, someone can plese help? i have a table with 2000 users and another table with about 10000 different items.
every user will see a list of these items. now i want a user to tag the item he does not want to see in his list (deactivate them) , other users might need to display the item. how can i manage this?
i hope you understand my question 
THX
I’d create a table for the items a user doesn’t want to see, let’s call it User-Item.
Inside it, you’d have the fields:
Then, in the specific searches you need to run, just add a constraint to exclude the items that appear in the list of items the user doesn’t want to see.
Something like this:
This way, each user would only see the items they actually want to see.
I’ve been looking for a good solution to this for quite a while too (letting users choose which items to hide).
Most of the approaches I’ve seen use lists, but they don’t scale well in my experience. Lists get slow fast.
Using a join-table with individual records (instead of lists) is the most scalable option, but it can quickly turn into a huge amount of data. Once you have thousands of users each hiding hundreds of items, you’re suddenly dealing with millions of records. That also means you need to think about clean-up logic, for example, what happens when a user account is deleted, or when one of the hidden items no longer exists. It’s simple enough at a small scale, but becomes messy as things grow.
I’ve thought about offloading this to a third-party database or even using browser storage, but neither option feels quite right and have their own issues.
Tbh I’m very interested to hear how others have handled this or any good suggestions.
One way or another, we will have to have these lists somewhere, but in Bubble, creating them is not as flexible as we would like.
Mainly because we are unable to create the best privacy rules for these conditions.
In Supabase, we would do something similar, but it would be faster and we could easily create RLSs for these conditions, making it more efficient and scalable.
Since this is a Many to Many relationship, I would suggest creating an intermidiary table with the “User“ & “Item“ fields in it. Each time a user selects an item, it’s added to this table
@bitmovers @carlovsk.edits As this search will be quaite performance entensive , and cost lot of WU, doing the comparasion of dislike item in user end , is not a good solution it will slow the app.
what i suggest , inside the table of Item, add two more field , Intrested Not_Intrested.
and put each user to there respective field depending on weather they like it or not.
This way when we search the Item table, we can add a constraint User Is not in Not_Intrested and this will all happend inside bubble server.
Now a question will come all other field will contain each of there liked & disliked user Unique ID, firstly it will not be much data as we only have there unique ID, and secondly we can hide it with privacy rule.
The problem with having this list directly on the item is scalability.
A list-type field can only store up to 10,000 items/IDs, according to Bubble’s official documentation:
If the app is small, this probably won’t cause any issues.
However, if there’s a chance the app will grow and some items might accumulate very large lists, this limit could become a bottleneck.
There are chances but its very unlinked that a Item is being disliked by 10K people,
but you are right , this can be a Problem when app got old, you can also use a 3rd party Database for this purpose, only for this purpose, but then fecthign data and comparasion will be a nightmare.
in this case the only option is use a seperate data type but this also beigns its edge cases.
