Conception de bases de données

Question

Je voudrais que les utilisateurs puissent créer leurs comptes (qui stockent les informations de login et de mot de passe - table Accounts) et une fois que l'email est vérifié, ils ont la possibilité de créer leur propre enregistrement de personne (qui stocke les autres informations telles que le prénom, ... - table People). Je veux également que les utilisateurs (titulaires de comptes) puissent créer des enregistrements de personnes autres que les leurs. Ainsi, lorsqu'ils créent leur propre fiche de personne, les utilisateurs ont la possibilité d'accepter une fiche de personne qui a été créée par quelqu'un d'autre au lieu de créer leur propre fiche ou même de télécharger un profil à partir d'autres sites de réseaux sociaux et de créer la fiche de personne.

Chacun de ces titulaires de compte dispose également de plusieurs messages d'autres utilisateurs et d'autres contenus de réseaux sociaux tels que des blogs, ... Ma question est de savoir s'il faut associer ces messages, blogs, emplois,... au account_id ou au person_id ?

\================================================================================= UPDATE : Bon, je crois que je n'ai pas été très créatif dans la formulation de ma question. Dans une application simple, je pourrais créer une seule table USERS et stocker toutes les informations de connexion ainsi que les informations de l'utilisateur telles que le prénom, ... et associer les messages, et d'autres choses avec le user_id.

Mais comme je veux que les utilisateurs puissent créer de nombreux enregistrements de personnes (non seulement pour eux-mêmes mais aussi pour d'autres, qui peuvent inclure des informations sur les utilisateurs qui n'ont pas encore créé leurs comptes), je pense séparer les informations de connexion dans la table ACCOUNTS (ou la table USERS) et les informations de profil dans la table PEOPLE. Chaque titulaire de compte n'aura qu'un seul enregistrement de personne (le sien et c'est l'information qui l'identifie au monde entier, car les informations de connexion ne servent qu'à l'authentification du système). Imaginons que VOUS ayez créé un compte ainsi que votre enregistrement de personne, et que vous voyiez la personne Bill Gates et souhaitiez lui envoyer un message, nous avons deux scénarios : (1) L'enregistrement de personne de Bill Gates n'est revendiqué par aucun titulaire de compte comme étant sa propre personne.
(2) L'enregistrement de personne de Bill Gates a un titulaire de compte associé Dans le scénario (1), le système ne vous laisse même pas envoyer un message car il n'y a pas de titulaire de compte qui pourrait vérifier les messages et dans le scénario (2), dois-je enregistrer l'identifiant de la personne BillGates dans l'identifiant des destinataires de la table MESSAGES ou BillGates.account.id ? La même chose s'applique à tous les autres types de contenu, comme les blogs, les photos, ...

Voyons voir, si je peux assembler les relations de la table :

ACCOUNTS
id
login
password
person_id (account holders personal record)

---

PEOPLE
id
first_name
....
creater_id (current_account().person.id or just the current_account().id ?)
updater_id (current_account().person.id or just the current_account().id ?)

---

MESSAGES
sender_id (current_account().person.id or just the current_account().id ?)
receiver_id (person.id or person.account.id ?)
subject
body

---

BLOGS
id
title
body
author_id (current_account().person.id or just the current_account().id ?)

J'espère avoir été clair. Si ce n'est pas le cas, faites-le moi savoir, je vais essayer de trouver d'autres exemples.

Answer 1

Je dirais que cela dépend d'un objectif. Si vous voulez spécifier la propriété d'un message, d'un article de blog, etc., j'utiliserais account_id car la personne doit être authentifiée pour créer un tel enregistrement.

Si vous voulez marquer qu'un message fait référence à d'autres personnes, alors j'utiliserais people_id.

Answer 2

Vous le dites déjà vous-même. "Chacun de ces titulaires de compte ont aussi..."

Les titulaires de comptes ont des messages, des blogs, etc. Ils doivent donc avoir des identifiants de compte. Si vous voulez que les personnes sans compte aient ces messages, vous devez utiliser des person_id.

Answer 3

S'il y a toujours exactement une personne associée à un titulaire de compte, alors ils décrivent en quelque sorte la même chose, et donc l'endroit où vous placez le blog, les messages, etc. n'a pas d'importance. Dans ce cas, j'irais avec ce qui est le plus intuitif puisque cela n'a pas d'importance structurellement, ce qui signifierait probablement de le mettre dans la table Personne.

D'autre part, si vous suggérez que plus d'une personne peut être associée à un compte, ou que vous voulez que les gens puissent d'une manière ou d'une autre avoir des blogs, des messages, etc. même sans compte associé, alors évidemment ces choses ont à loger dans la table Personne.

Edit : C'est très Il est important de mettre une contrainte individuelle unique sur la clé étrangère (quelle que soit la table dans laquelle vous finissez par la placer). Sinon, votre association un-à-un peut facilement devenir un-à-plusieurs par accident si un utilisateur négligent entre, par exemple, une nouvelle ligne de titulaire de compte et lui donne le même "ownerID" qu'un titulaire de compte précédent. Dans ce cas, le ownerID est une clé étrangère de la table Person et nécessite la contrainte unique.

Edit #2 : En regardant la clarification de votre question, je ne vois aucune raison de ne pas avoir une seule table "USERS". Il suffit d'avoir un attribut booléen "acitivated" qui signifie que cette personne a un compte actif avec des informations de connexion valides. Lorsqu'une personne crée un compte mais n'a pas saisi d'informations personnelles, "activated" sera vrai mais les champs d'informations personnelles resteront NULL. Et si cet utilisateur crée les profils d'autres personnes, de nouvelles lignes seront insérées dans USERS contenant toutes leurs informations personnelles mais les champs "nom d'utilisateur" et "mot de passe" seront NULL et "activated" sera faux. Ne serait-ce pas la solution la plus transparente et la plus simple ? User et account_holder sont la même chose (c'est pourquoi vous obteniez une association biunivoque), alors pourquoi ne pas tout laisser dans une seule table ?