Database - general question

ramzizi · 2024-12-14T23:30:02.360Z

Let’s say I have a user on an appointment type app where they manage bookings. There are two data types

User
Bookings - contains individual appointments

In the past, if I wanted to display all of an individual User’s appointments, I would run “Do a Search For” where Booking’s created by = that user. But I realized that is very work unit heavy.

So now, I created a field Bookings within User. When a Booking is created, this Booking is added to the list in User:Bookings. Now when I want to display a user’s bookings, I can just display Current User’s Bookings. It uses much less Work Units.

But as my app is becoming more popular and some users have hundreds of bookings, I’m starting to notice a slight increase in loading times. Is approach I’m taking not the best idea?

randomanon · 2024-12-15T00:59:15.094Z

It is an unwritten rule that lists generally “top out” at around 100 items. You generally don’t want to use lists beyond that, or if you need to use specific filtering/constraints etc.

mitchbaylis · 2024-12-15T02:48:18.487Z

You’d be best storing the user on the booking and then searching for the bookings for the user.

A user could have hundreds/thousands of bookings and loading that list whenever the user is loaded (users are loaded on page load every time) would be super heavy. (the list would be loaded even it if isn’t used on the page since it’s stored on the user which is loaded on every page load).

Further, you’d be best to page the bookings in the repeating group to reduce the data sent to the page. Paged to 10 or 20 would be a good starting point.

If you frequently accessed the most recent booking you may want to hold that on the user so you don’t have to search for it constantly.

ramzizi · 2024-12-17T02:32:05.748Z

Thanks for the advice! Is this a problem unique to Bubble? Or is it a general rule in programming to limit lists to 100? Seems so restrictive to me

sem · 2024-12-17T04:55:53.896Z

Mostly in programming you normalize which means in your case that you have a table with one booking per row per user and you simply fetch all the bookings that belong to that specific user.

So suppose you use Postgres and you have 1.000.000 users and 10.000.000 bookings you query to get the specific bookings for that user and it will return for instance one user and 1.000 bookings in 50 milliseconds and you can do that 1000 times a second on a $5 VPS server.

That’s why currently it is good to learn about Bubble specifics because what you normally would do in programming is either slow on Bubble or economically not feasible.

system · 2025-02-22T23:30:11.066Z

This topic was automatically closed after 70 days. New replies are no longer allowed.