I'm completely new to backend, and the rules related to what data is retrieved from the database on which queries is lost on me. Does anybody have a great resource for best practices on model design and database queries?
For instance, I'm making a social media site where the profile asks about personal anecdotes, so several questions associated with a user could be paragraphs long. Would it be way better to have a series of 1-to-1 relationships for each of the different questions, or just store the potentially paragraph long answers with the user itself. My intuition is to do a one-to-one relationship and eager load on the occasions that I am actually retrieving those answers and listing them out...?
Thanks for any advice!
Hi @commish I think the scope of your question its too big.
Could you share the code of the models you want to implement?
Sometimes things just get clear with the hands on it. Also if you follow clean code practices you could refactor your code if somethings its wrong.
Regards
Hey @punksolid, thanks for replying! I'm actually building this from scratch starting today; it's my first laravel app that isn't relying on a tutorial, so as I create this model, I'm wondering what the best practice are for storing large data associate with a user.
For example, the profile has questions like "What do you like to study in your free-time?" And "Describe a time you did something nice for someone without expecting something in return." These questions could be answered with responses that are paragraphs long, and it seems like for example every time I grab a list of users, that it would be expensive to the database to grab these paragraphs and paragraphs every time I want the list of users.
So I guess my question is, when you simply get a list of users, does it also grab all the columns associated with a user entry in the database? For large chunks of data like the profile image or these long responses, is there a best practice to decouple these data-heavy columns from the returned user object, or is that where one-to-one relationships come in?
Cool @commish now I understand.
Keep the user model as simple as possible, for data related to a profile use a relationship 1 to 1, there you could store anything, so yes, 1 to one its the right path. If there are a lot of columns for your profile model, then maybe you could separate by their purpose.
But don't attach at first those to your user table.
Please or to participate in this conversation.