One Big Data Type or More Smaller Ones?

Hi folks…

I am just designing my database structure for an app which I will sell and (hopefully!) have hundreds of users over the coming few years.

Could anyone help me understand the pros and cons of having a smaller number of large data types versus a larger number of small ones? So right now I am designing a significant number of settings fields linked to each user, and I’m wondering whether to put all the fields in the User data type, or create a separate type called User Settings.

Any thoughts on how one method or the other may impact the functionality I can offer or the speed and resource usage of the app would be greatly appreciated! :slight_smile:

Hey, Antony.

When I first started out I was mostly using the first approach you described: a small amount of large data types. But as the number of field in a data type grew I came to the conclusion that it really hampers your ability to work with the data types.
For example when you start updating your user info via the ‘Make change to thing…’ workflow you would end up swamped with needless data fields. At least for me it’s mostly a navigation issue, I like things neat and tidy. Hope this helps.
Best of luck with your app!

Thanks for the prespective @footballresearchprue. Yes, that is my inclination too, but I wanted to be clear in a big database how much of a performance overhead that will bring.

Does anyone else have experiennce of the impact on performance?

It depends on the data you want to save and how to use them later.
There is a subject in database theory: “database normalization” that could be interesting for you. Shortly - you check what data is similar and split it into smaller entities.

Example: imagine you store user invoices. One table would be like this:

surname, name, email, address, date, value, item, item price, quantity
(bit different on bubble since there are lists, but still…)

in this case you can easily see that lots of data will be repeated (storage space) + possible discrepancies (what if eg, surname or address is once typed wrong) and each time you want to see small info about user - you fetch all data about his invoices (at one stage it will hit performance - depends on the amount of data you gonna deal with)…

After normalization - this translates to few tables:
name surname address email

name price

User_order (invoice)
user, value, shipping address, date

Order_items (invoice positions)
invoice, item, qty, price

As you can see - easier to manage, access, update, present… Maybe you could give some examples what you want to store.

Additionally, with bubble - you have data privacy settings. If some data should be visible to only users, other to others - it may be easier to manage with more Things in place.
Now, the performance - theoretically (haven’t tried yet) with bubble you can scale the solution if needed. So ask yourself how often you will need small pieces of data = 1 small query vs big pieces of data = many small queries / one big

Hope that helps.