In database design, there is something called “normalization”. Typically, you never repeat the same piece of information in 2 different tables in a database … Most relational models will encourage you to do this. You can look up “Boyce-Codd” if interested.
But when performance matters, sometimes the easiest way around is to duplicate a column’s value into another table. That is called “denormalization”.
You just need to be very vigilant about update that value in cascade. In your case, if the e-mail changes, you may need to update potentially hundreds of lines in another table to keep the consistency.
So, there is a trade-off, and it usually implies choosing strategically where and how you duplicate that data to be the most efficient overall.
Already, in a regular database query with SQL such as MySQL, SQL Server, Oracle etc… “joining” tables is always the most expensive operation. But databases are very fast.
Here with Bubble, the problem is much worse. Here, all the advanced filtering is done via the browser and imports large quantities of data… it imports different data sets and then compares them and does the filtering in the browser. Only the initial relatively simple query is done in the database. Much slower…
There are certainly valid reasons or technical explanations, but I don’t really understand why the query builder has to execute so much of the filtering in the browser though. Why can’t we have the same interface we have, but also have a mode where we can do more complex queries directly in the database? Perhaps even an “SQL preview” for power users such as agencies or users who have worked with traditional database systems in the past…
EDIT: Come to think of it… AWS is not cheap (in Europe, a dedicated server with OVH for example is MUCH cheaper), and database calls are among the expensive things with them. But Bubble runs on AWS. That is probably why they do it that way lol