2011-08-28 3 views
1

Je développe un site Web en utilisant PHP et MySQL où les utilisateurs ont des options telles que:Paramètres utilisateur/Confidentialité Database Design

  • recevoir des notifications par email
  • cacher/afficher Facebook/Twitter Liens

Il permettra également aux utilisateurs de contrôler la confidentialité de leur profil à partir d'informations visibles aux amis/non-amis et quels amis sont en mesure d'afficher certaines photos/albums.

Je me demandais comment je pourrais concevoir cette table pour qu'elle soit robuste et quels éléments devrais-je prendre en considération. Comment Facebook gère-t-il les paramètres et les options de confidentialité de chaque utilisateur par simple curiosité?

Ma solution à ce jour est le long des lignes de ce:

id - clé primaire

member_id - Clé primaire et clé étrangère (s id 'tables de membres)

facebook_viewable - int (1) - 0 pour Non et 1 pour Oui

email_notifications - int (1) - 0 pour Non et 1 pour Oui

+4

peut-on écrire un site Web qui n'a rien à voir avec twitter de facebook s'il vous plaît. –

+1

Google Plus ...? – unleashed

+2

Sans rapport, mais vous voulez tinyint, pas int. Le (1) à la fin n'affecte pas la taille des données, de sorte que les zéros et les uns prennent autant de place qu'un int. C'est une idée fausse commune. – Aaron

Répondre

7

Tout d'abord, vous ne avez probablement pas besoin d'avoir à la fois id et member_id si les deux vont être primaire. Vraiment, vous avez besoin member_id de sorte que vous pouvez simplement laisser tomber l'autre id. Pour être robuste, ce que vous voulez, c'est conduire les paramètres en rangées plutôt qu'en colonnes. Il est beaucoup plus facile, du point de vue de la base de données, d'ajouter des lignes que de modifier la table pour ajouter des colonnes. Vous avez besoin d'une table contenant une liste de vos types de règles de confidentialité, puis une table d'intersection entre votre table de membres et votre table de types de règles de confidentialité. Le schéma serait quelque chose comme ceci:

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) 

De cette façon, l'ID de la règle de confidentialité devient une constante dans votre code d'application qui est utilisée pour appliquer la règle réelle programmation et les valeurs peuvent être ajoutées facilement à la table d'intersection. Lorsque vous inventez une nouvelle règle de confidentialité, tout ce que vous devez faire est d'insérer un enregistrement dans PRIVACY_RULE, puis de modifier le code de votre application. Aucun changement de schéma de base de données requis.

Notez que cette même structure de base peut être élaborée pour la rendre beaucoup plus flexible. Par exemple, vous pouvez avoir plusieurs types de valeurs au-delà d'un indicateur binaire et vous pouvez contrôler l'interprétation de ces valeurs avec un attribut "rule type" supplémentaire sur le tableau PRIVACY_RULE. Je ne veux pas aller trop loin du sujet avec ceci alors laissez-moi savoir si vous voulez plus de détails de cet aspect.

+0

trucs cool, comment voulez-vous faire face à "qui peut voir mes photos: tout le monde | amis | coutume"? –

+3

Comme j'ai commencé à faire allusion à dans ma réponse, si vous voulez, il serait facile d'étendre "rule_value" d'un drapeau bit dans une énumération. Cela pourrait gérer des paramètres multivalués comme n'importe qui | amis | amis d'amis et ainsi de suite. Vous pouvez également personnaliser en appliquant des règles aux objets appartenant à des membres. Cela nécessiterait une autre table qui ressemble à 'MEMBER_PRIVACY' mais qui inclut un FK à l'objet (photo/page/...) –

Questions connexes