Help with first project (+1 to database)

Hi, I am trying to figure out how to set this scenario up. My first project in Bubble.

I have 2 buttons: Yes and No.

The user has an age range for ex. 18-25.

Once he clicks on yes, I want to save in the database, that the number of people in the 18-25 age range has increased by 1.

What would be the formula to use in the workflow? Attached is the screens of the DB structure so far.



You simply repeat the field and do “+ 1. Repeating the field means it will take the value of the field and since it is a number type field you can add any increment to it

But I don’t see any options to repeat it:/

Do you really?

When you want to know how many users are age 18-25, all you actually need to do is Do a search for users:count with constraints for Age >= 18 and Age <25.

That will always return the correct number of users between 18 and 25. You can place this expression anywhere on your Bubble app, including on the page using a text element if you want to see it.

2 Likes

This is the right answer. The database should NOT store a number that tells you the number of [object]s in the database

That depends. Do a search for can user lots of WUs. Not sure what the exact use case is. Perhaps a event platform used for only registration?

This expression will only ever cost 0.2WU, irrespective of how many users are in the database.

Interesting!

I was under the impression that it does matter how many records there are but perhaps I have misunderstood the manual on this part:
Starting the aggregation calculation has a cost of 0.2, but the data to be aggregated needs to come from a data source. In many cases, this will be the result of a dynamic expression using the Do a search for data source.

What this means, is that this operation needs to be added to the total calculation. According to the activity type chart, a database search has a starting cost of 0.3. The complexity of that search can add to the cost of it.

Given the fact that you help people with optimizing for WU I am inclined to take your word on it. Do you know why there are no increasing costs for a do a search for when there are many rows to search for?

Do a search for Things ≠ Do a search for:count

Do a search for Things returns Things (0.3WU plus Things returned) , Do a search for:count is an aggregate query. Only 0.2 WU is charged (and it’s therefore cheaper than a standard search).

Because Bubble doesn’t charge for it, but the reason they don’t charge for it is likely because the database volume doesn’t substantially impact the resources it takes to run an aggregate query.

Thanks for the information. As I have no other information than that it does cost about the same resources to run an aggregate function in postgres as it cost to run the function itself, I thought bubble would price it as such. But it could be the case that as of this moment the aggregate queries costs are less. I am not a postgres expert ;).

It’s just bad practice to build conflicting information into your database. If you have a table of users whose properties are fixed, you shouldn’t have a separate table which is derived from those properties because then you are creating an obligation on yourself to keep those two facts consistent, when this is literally the point of the database.

It would be like checking out a book at the library, and then having to fill out a form saying what book you checked out- like, they already know what book it was because you checked it out.

1 Like

True but because of WUs you sometimes have to. Besides, lots of things the Bubble way are not the “standard” db way.

Verzonden vanuit Outlook voor iOS

1 Like