Is less more - or will I live to regret it?

Need help Database
1

For general speed and flexibility, would it be better to have a database set up like option A:

  • 50 more granular custom data types
  • fewer fields per custom data type
    (some data duplication between data types is likely - for example the same image might be uploaded on multiple records in different data types)
  • ~100 entries/records per day, per custom data type over time

Or option B like this:

  • 5 very broad custom data types
  • more fields per custom data type
    (to allow subcategorization & relationships/linking with other data types)
  • 1,000 entries/records per day, per custom data type over time

Considering performance over time, which option would you go with? Option A would result in about 40k records per year in 50 different data types, whereas option B would result in 1.8m records per year in 5 data types.

In non-Bubble data systems, I have previously developed using option B and using database relationships and filters to get the data I need. This was because the slowest part of other systems I have used has been the display component – the database backend was lightning-fast.

However, the Bubble tutorials and examples I’ve come across all seem to go with option A and my gut says to go with A in Bubble to avoid having to filter a large dataset.

What do you think? Thanks for helping me clear this up!

2

Both :slight_smile:

It really depends on your exact use case but I typically start my data structure with option A and come back towards option B wherever I can.

For instance, say I’m creating contacts and I want to store two phone numbers for each contact. I could either create a single data type of contact (option B) that looks like this:

CONTACT

  • First Name - text
  • Last Name - text
  • Telephone1 - text
  • Telephone1 Type - text
  • Telephone2 - text
  • Telephone2 Type - text

or two data types (option A) that would look like this

CONTACT

  • First Name - text
  • Last Name - text
  • Telephone - List of TELEPHONES

TELEPHONE

  • Type - text
  • Number - text
  • Contact - CONTACT

Obviously both options will work but option B will display phone numbers immediately in a repeating group and option A will have a teeny weeny little delay.

However, with option A we can create 1 to infinity telephone numbers for each contact (substantially more scalable and maintainable) while with option B we are stuck with a max of two telephone numbers without actually diving back into the app and doing more development work.

If I’m certain I won’t ever need more than two telephones per contact, I would go with Option B. If I think there’s a slight possibility it may need to scale past two telephones, I’ll choose Option A.

TL:DR - I err on the side of option A as a default but its a decision to be made at the granular level of your data structure. There’s not a right or wrong way from a birds-eye view.

3 Likes
3

eli, thank you for your help - I didn’t expect “both” to be an option, but your contacts example helped me understand what you mean.

I think what you refer to as option B is what I was trying to explain as my option A, but I followed what you were saying and it reinforces my gut feeling about how to approach this. Thanks again.

1 Like