CODEWITHSUNDEEP
phpmysqldatabasedatabase-design
unleashed
unleashed

Reputation: 925

User Settings/Privacy Database Design

I am developing a website using PHP and MySQL where users have options such as:

It will also allow users to control privacy of their profile from information viewable to friends/non-friends and what friends are able to view certain photos/albums.

I was wondering how I would design this table to be robust and what things should I put into consideration. How does Facebook manage each users privacy settings and options just out of curiosity?

My solution so far is along the lines of this:

id - Primary Key

member_id - Primary Key and Foreign Key (Member tables 'id')

facebook_viewable - int(1) - 0 for No and 1 for Yes

email_notifications - int(1) - 0 for No and 1 for Yes

Upvotes: 1

Views: 2574

Answers (1)

Joel Brown
Joel Brown

Reputation: 14388

First off, you probably don't need to have both id and member_id if they are both going to be primary. Really you need member_id so you can just drop the other id.

To be robust, what you want is to drive settings into rows rather than columns. It is much easier from the database perspective to append rows than to alter the table to add columns.

What you need is a table that contains a list of your privacy rule types and then an intersection table between your member table and your privacy rule type table. The schema would be something like this:

MEMBER
  id int not null PRIMARY KEY
, name nvarchar(50)...
, (and so forth)

PRIVACY_RULE
  id int not null PRIMARY KEY
, rule_description  nvarchar(50)

MEMBER_PRIVACY
  member_id int not null
, privacy_rule_id int not null
, rule_value tinyint
, PRIMARY KEY (member_id, privacy_rule_id)

This way, the privacy rule ID becomes a constant in your application code that is used to enforce the actual rule programmatically and the values can be added easily to the intersection table. When you invent a new privacy rule, all you need to do is insert one record into PRIVACY_RULE and then do your application code changes. No database schema changes required.

Note that this same basic structure can be elaborated on to make it much more flexible. For example you could have many different types of values beyond a binary flag and you could control the interpretation of these values with an additional "rule type" attribute on the PRIVACY_RULE table. I don't want to go too far off topic with this so let me know if you want further detail of this aspect.

Upvotes: 7

Related Questions