Projectthat 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 one below, where you find all messages that belong to threads that are linked to a project. However, this nested search (search inside a search) will 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.
Messageobject directly to the
Projectobject, 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 constraintsis checked and the
Group email, which means that if
Group emailis 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 constraintsoption to get away with using a single search expression for the repeating group.
When page is loadedbut, 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.
Projectand an object called
Invoice. Each project can have multiple invoices. The default database structure would be to create a
Projectfield on each
Invoiceobject 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 invoiceson each
Projectand refer to that list directly instead of doing a search.
Songand 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 songson each
Tagbecause that list may get very large and Bubble struggles working with large lists. Instead, we should have a field called
List of tagson each
Songand always perform a search for songs if we're looking to access songs that have a particular tag.