Во-первых, вам, вероятно, не нужно иметь оба значения id и member_id, если они оба будут первичными. На самом деле вам нужно member_id, чтобы вы могли просто бросить другой id.
Чтобы быть надежным, вам нужно поместить настройки в строки, а не в столбцы. С точки зрения базы данных гораздо проще добавлять строки, чем изменять таблицу для добавления столбцов.
Вам нужна таблица, которая содержит список типов правил конфиденциальности, а затем таблицу пересечений между таблицей членов и таблицей типов правил конфиденциальности. Схема будет выглядеть примерно так:
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)
Таким образом, идентификатор правила конфиденциальности становится константой в коде вашего приложения, который используется для программного применения фактического правила, и значения могут быть легко добавлены в таблицу пересечений. Когда вы изобретаете новое правило конфиденциальности, все, что вам нужно сделать, это вставить одну запись в PRIVACY_RULE, а затем внести изменения в код приложения. Изменения схемы базы данных не требуются.
Обратите внимание, что эту же базовую структуру можно разработать, чтобы сделать ее намного более гибкой. Например, у вас может быть много разных типов значений, кроме двоичного флага, и вы можете контролировать интерпретацию этих значений с помощью дополнительного атрибута "rule type" в таблице PRIVACY_RULE. Я не хочу вдаваться в подробности этого вопроса, поэтому дайте мне знать, если вам нужны подробности этого аспекта.