DB Design: how to indicate if a column data is public or private - sql

Question

I'm designing a database and I have a question about how to make private some user data.
I have a user table, with name, city, birthday, biography, etc. And the user can make some data private (other users can see that data).
First, I thought to add columns to the table to indicate if a column is private or not. For example:
User
-------
user_id | name | city | cityIsPrivate | birthday | birthdayIsPrivate
---------+------+------+---------------+----------+------------------
Or, another approach is to add a varchar column to indicate which columns are private:
User
-------
user_id | name | city | birthday | privateColumns
---------+------+------+----------+---------------
And this privateColumns will have this: "city:NO; birthday:YES".
The user table will only have three columns that can be private or public. I will only have to add three columns more to the table.
Any advice?

Answer 1

Do not move data into a separate table if you are going to have to join to it every time you query the main table.
Boolean (or equivalent) columns to indicate privacy for every column on which a privacy setting can be applied:
is very simple to add.
takes up practically no space.
is much quicker to query.
shows that the privacy settings are an intrinsic part of the user data.
removes unnecessary complexity from the schema.
The facts that these relate to other columns and that they represent a single kind of logical object are just a distraction. Go for simplicity, performance, and logical correctness.

Answer 2

Move the list of you private columns to separate table whith three fields, like:
UserId |ColumnName |IsPrivate
-----------------------------
Then you can join your queries with that table and get proper result set for each user, and at the same time change the columns of yor user table.
If your User table would not suppose have changes, it is better to move the list of you private columns to separate table with proper structure, like this:
UserId |cityIsPrivate |birthdayIsPrivate
----------------------------------------
Then you can join your user table with this table in a single query and get result set your need.
But don't make it in the same table. The first approach brings redundancy to your database structure. In your second case you would not be able to make SELECT queries by IsPrivate criterias.

Answer 3

You can have a separate table (UserPrivateFields, for example) listing user ID's along with fields they have elected to make private, like so:
UserID | PrivateField
-------+-------------
1 | Name
1 | City
2 | Birthday
When you're running the procedure grabbing the user info to be pulled by the person requesting the info, you can then build a query like this (assume the desired user's UserID is passed into the proc):
CREATE TABLE #PublicUserFields (Publicfield varchar(50))
INSERT INTO #PublicUserFields (Publicfield)
SELECT Publicfield
FROM userPublicfields
WHERE userid = #userid
Declare #sql VARCHAR(MAX) = 'SELECT '
WHILE EXISTS (SELECT 1 FROM #PublicUserFields)
BEGIN
DECLARE #Publicfield VARCHAR(50) =
(SELECT TOP 1 Publicfield FROM #PublicUserFields)
SET #sql = #SQL + #Publicfield
IF (SELECT COUNT(*) FROM #PublicUSERFIELDS) > 1
BEGIN
SET #SQL = #SQL + ', '
END
DELETE FROM #PublicUserFields
WHERE Publicfield = #Publicfield
END
SET #SQL = #SQL + ' FROM MainTable WHERE userID = #userID'
EXEC(#SQL)
The reason I'm bothering with dynamic SQL is that the names of your public fields can't be joined directly to the column names of the main table with this setup - they can only be selected or joined to other records with the same string value. You could maybe get around this by joining to sys.columns and doing interesting things with the object_id of the columns, but that doesn't seem much easier than this appraoch.
This makes sense IF the users can all dynamically set which fields they want to be viewable by other people. If the private fields are known and static, you may just want to separate the two categories and tighten down the permissions on read-access on the private table.