Storing user profile fields and information in a scalable and extensible way
===

I am working on a social networking website focusing on a specific niche, and I had a question about storing user profile information. While I want users to be able to store information such as Gender, Occupation, Likes, Dislikes, etc. I also want to do it in such a way where, if I wanted to add any more profile fields in the future, I could do so easily and possibly even through an administrative interface.

Here is the database schema I have constructed so far:

**Users**

 * id (PK)
 * email
 * password (etc...)

**ProfileFields** (this would store fields such as "Gender", "Occupation", as well as what type of input to expect: text, list, checkboxes, radio buttons, etc.)

 * id (PK)
 * field_label
 * is_optional
 * value_type (enum: text, textarea, list, dropdown, checkbox, radio)
 * is_multiple_allowed (valid only for list, really)

**ProfileFields_Values** (this would store the preset selectable values for any given ProfileFields entry, for which there will entries only if the <i>value_type</i> is list, dropdown, checkbox, or radio)

 * id (PK)
 * guid (for HTML element IDs, etc.)
 * profile_field_id (FK: ProfileFields)
 * sort_order
 * field_value (preset value; e.g. "Male", "Female" for Gender)

**User_ProfileFields** (this would store user input for various ProfileFields entries)

 * user_id (PK, FK: Users)
 * profile_field_id (PK, FK: ProfileFields)
 * user_value (whatever the user entered; this would be an FK:ProfileFields_Values or text that the user typed in)

Profile fields such as "Gender" &mdash; which have preset values that the user can select &mdash; will implement the ProfileFields_Values database (to store the preset values), whereas fields such as "Occupation" &mdash; which are generally open-ended &mdash; will not.

Basically, I'm just wondering if this is sufficient. Are there are any problems that might crop up as a result of doing it this way?