I’m using for some tips on setting up the database efficiently. As I understand, following some sensible rules when setting up the database can shave time off loading and general responsiveness, so I’d like to adhere to a good set of practices early on. Here are a few questions.
Feel free to add more questions that are relevant if you want
Saving data to sub-data types, instead of in main data type
I hope I’m not getting the “database dictionary” too mixed up here and misusing terms. But here’s an example: You have a user saved (let’s call him Petter). He has a lot of settings saved, such as email, nationality, etc. I make a decision to save a large set of extra settings to Petter, and because there can be a lot of them, from a “human reading” perspective, it makes sense to set them up in an individual data type. Such settings can be “Has-finished-user-profile” (yes/no), “has-read-terms-and-conditions”, “has-received-welcome-mail”… etc. Over time it can be hundreds of different settings that makes the application more user friendly.
So, to sum up the dilemma: it seems easier for me to set up data types that are connected to the user, instead of saving hundreds of fields on the user itself. From a computer perspective, however, it may be quicker to save it all to the user. What is the recommended best practice here, to maintain an efficient database and minimize loading times? Keep in mind that I’d like to discuss choices that affect loading time and responsiveness in an observable manner (so if one choice over the other shaves a theoretical 1 millonth of a second of loading, it may still make sense to choose the “slower” one, if you get my point.) Let’s assume that this system would have thousands of users in the database, to allow for growth,
Data type: user
Data type: user_finished_pages_booleans
user_finished_pages_booleans data fields: