How to efficiently work with multiple database tab

问题:

I've giving myself a small project to help me improve with my ruby on rails programming. So far I've completed full user signup and authentication with password reset, a remember me feature and notification emails. I totally understand what is going on.

So I've now moved to the user account area and would like to code the page that my user would edit their profile on. My signup form only asked for username, email and password as I wanted quick registration. For the page where users will edit their profile information it will ask them for things such as:

first name last name date of birth location it will have the url for their profile about me personal stats favoyrite things status etc and their photos

They should be able to update or change this info on the fly. On their actual profile page it will pull this info for their profile content.

I was wondering to keep organised would it be best to created a separate table for this e.g. profile? or would it be wise to store some of this info in the users table in the database, such as first name last name?

I'm trying to figure out a clean way to do this because later on I'll need to add more pages like the settings page etc.

This is the first time I'll be working with multiple tables and I have an idea how to do it but not too sure. Any advice such as a brief explanation of how you would achieve this would be appreciated.

Regards

回答1:

I know I will get flak from people for oversimplifying a subjective situation. But at times an open discussion around the scenarios that make the situation subjective can help in decision making. So, here is my take.

Are you using devise or some such gem for the authentication piece? If yes then you probably have the tables created per the requirements of that gem. If you look at separation of concerns, whatever is needed for the authentication + authorization system is pretty much encompassed in your existing user table. I would approach it by asking - is there any benefit of coupling your profile data (especially if it is more than a couple of text fields) with this table? I don't see one especially given the fact that profiles or user-generated permanent data are no longer guaranteed to be just one picture and 2-3 text fields. For example, on social networking sites the profile can take a life of its own.

Also, what happens if your site takes off. If you have an active user base that adds/updates pics, location info and other data to the profile, do you want that to start impacting your authentication tables? If you hit a resource crunch, a standalone authentication system can be your last concern. But not so if it has been coupled with everything user-related.

So, yes it does depend on your particular circumstance but I hope my thoughts above provide you some clarity on why the decision may differ based on the type of the site. If the user is at heart of your system and user interactions are key to the profile (e.g. social networks) definitely think about keeping the two areas separated. If user profile is probably just one-line about the user then it is not a big concern. If you are doing this purely for learning, try it out both ways because you will have more arsenal for future challenges.

回答2:

I don't see the need for having a separate table for user's profile. I say so cause right now the relationship between user and profile is a one-to-one relationship. A user will only have one profile. Unless user will have more than one profile, I don't think you need a separate table for user's profile. YOu can simply add additional columns to the user table to store user's (optional) attributes.

On your form, when the user has not yet set attributes that are required during registration, you can simply leave them as blank. For users who have set these optional attributes, you can show them on the edit form by setting the value attribute of the input tag

<input value='dennis' name='user[first_name]'/>

The button will always do an update and save the users attributes.