I’m setting up a site that will have several hundred (or more) categories. These categories will have a lot of meta associated with them. Each category can have more than one parent category, and have many children.
Categories will be linked to nearly every other data type in the system, some of which will contain hundreds of thousands of records.
I will need to manage those categories frequently, and I’m OK with doing this in the Bubble editor, but prefer to build an interface for this.
I understand option sets are faster and avoid database calls. However, I see them more as static lists that rarely change, and have a relatively small record count.
Any advice on whether I should go with a standard data type or option set for categories as I described them?
Thank you.
Is this a solid observation.
This answers the question for you, that option sets are not a viable option for your use case.
For me, anytime I need to update the data, I pretty much automatically rule out Option Sets
3 Likes
You can also create a data type for the “categories” but still have an option set on it. I did this recently for “asset types” in an app.
The user wanted to be able to edit the asset types and add/remove them - so they couldn’t be option sets.
But certain asset types trigger actions and filters in the app logic so I added a “system asset type” to the asset types. This way my filtering logic is easy as I’m referencing an option set instead of an id, and the user still gets the functionality they want.
Most of the asset types ~ 80% are not used in the logic so the option set gives me simplicity and hides the logic from the user. I also use it to hide the delete for the system asset types so the user couldn’t stuff up my logic.
Option sets are very useful and I will occasionally add hidden option sets just to make the logic easier/faster to map and understand for frequently used parts of the logic where I have specific data triggering things.
