Project
that has multiple Message Threads
, each of which has multiple Messages
. If you want to find all messages within a particular project, you may want to do a search like the below, where you find all messages that belong to threads that are linked to a project. However, this nested search is likely to take longer because Bubble first has to find all of the threads that belong to a project and then find all of the messages that belong to one of those threads.Message
object directly to the Project
object, which seems redundant (as you can always reference Message's Message Thread's Project
) but also allows you to make your search more direct and thus faster.Ignore empty constraints
is checked and the email
field is set to the value of Group email
, which means that if Group email
is ever empty, the search will ignore the email constraint and will return ALL of the users in the database. There are a few ways to remedy this:Ignore empty constraints
. This is the easiest but is also sometimes bad advice because this feature can keep your search expressions cleaner. For example, if you have a repeating group that you want to show all of the users and a search box on top of that repeating group that the user can enter a keyword in to filter the repeating group, you can use the Ignore empty constraints
option to get away with using a single search expression for the repeating group.Group email's
value When page is loaded
but, if you do that, there will be a split second before the page is loaded, when the group is empty. And during that time your repeating group may try to load all of the Users into it, which will slow the entire application down.Project
and an object called Invoice
. Each project can have multiple invoices. The default database structure would be to create a Project
field on each Invoice
object and then Do a search for Invoices where Project is equal x
. However, if you're looking to speed up your application a bit, you may want to create a List of invoices
on each Project
and refer to that list directly instead of doing a search.Song
and an object called Tag
. Each song can have multiple tags (classical, rock, etc.) applied to it. In this case we wouldn't want to store a List of songs
on each Tag
because that list may get very large and Bubble struggles working with large lists. Instead, we should have a field called List of tags
on each Song
and always perform a search for songs if we're looking to access songs that have a particular tag.