J'utilise Postgresql. J'ai besoin d'aide pour trouver la meilleure façon de concevoir ma base de données. À la base, mon application Web comporte une entité que j'appelle une collection d'éléments - pensez à "10 livres à lire absolument sur l'espace ...

0
asanas 15 mars 2021 à 11:18

2 réponses

Meilleure réponse

Puisque vous utilisez Postgres, vous souhaitez normaliser vos tables. Ce que la normalisation signifie, dans une phrase, c'est que vos colonnes sont représentées par la clé, la clé entière et rien que la clé. La normalisation peut être un processus en trois étapes, mais je vais juste montrer le résultat final.

Généralement, dans une base de données, les noms de table sont singuliers. Utilisateur, collection, article. De plus, il est moins déroutant de nommer vos champs ID avec le nom de la table. Cela facilite la lecture de Join SQL.

Commençons donc par la table User.

User
----
User ID
User Name
User Email
...

Jusqu'ici tout va bien. Toutes les colonnes ont à voir avec un utilisateur.

Ensuite, regardons Collection

Collection
----------
Collection ID
Collection Name
Owner ID

Jusqu'ici tout va bien. L'ID du propriétaire est l'ID utilisateur du propriétaire de la collection.

Ensuite, regardons Item.

Item
----
Item ID
Item Name
Item Description
...

Jusqu'ici tout va bien. Toutes les colonnes ont à voir avec un élément.

Examinons maintenant la relation entre la collection et l'élément que vous avez décrite dans le problème 1. Une collection peut avoir un ou plusieurs éléments. Un élément peut être dans une ou plusieurs collections.

Lorsque vous avez une relation plusieurs-à-plusieurs, vous créez une table de jonction. Créons donc une table de jonction CollectionItem.

CollectionItem
--------------
CollectionItem ID
Collection ID
Item ID
CollectionItem timestamp
CollectionItem contributor ID

Où CollectionItem ID est la clé de clustering principale. Vous avez également un index unique sur (ID de collection, ID d'élément), de sorte que vous pouvez rassembler la collection. Vous pouvez également avoir un index unique sur (ID d'élément, ID de collection), afin que vous puissiez voir quels éléments se trouvent dans plusieurs collections.

Vous avez également un index unique sur (ID de collection, ID de contributeur CollectionItem). Cela vous permet de voir quel contributeur (utilisateur) a contribué l'élément à la collection. Cet ID utilisateur peut être l'ID du propriétaire de la ligne des collections ou un autre contributeur.

En regardant le problème 2, nous avons besoin d'une table de vote. La table Vote est une autre table de jonction reliant une collection, un élément et un électeur (utilisateur).

Vote
----
Vote ID
Collection ID
Item ID
Voter ID
Vote timestamp

Où Vote ID est la clé de clustering principale, et vous avez un index unique sur (ID de collection, ID d'élément, ID d'électeur). Vous pouvez également avoir deux autres index uniques, selon que vous souhaitez ou non regrouper les votes par électeur ou élément.

Modifié pour ajouter:

Vous avez également besoin d'une sorte de table d'autorisations.

Permission
----------
Permission ID
Owner ID
Contributor ID

Où Permission ID est la clé de clustering principale et vous avez un index unique sur (Owner ID, Contributor ID). Vous pouvez également avoir un type d'autorisation, que vous n'avez pas défini, donc je ne peux pas l'ajouter à la table des autorisations. Le type d'autorisation ferait également partie de l'index unique.

J'espère que cette explication a été utile.

0
Gilbert Le Blanc 15 mars 2021 à 09:30
  1. Chaque collection a un auteur, donc avoir une colonne d'auteur dans la table de collection est parfait.
  2. Cependant, chaque collection peut avoir plusieurs éléments, ce qui est une relation m: n.
  3. Ensuite, vous souhaitez que les autres utilisateurs soient autorisés à ajouter des éléments à une collection. Un utilisateur peut être invité à plusieurs collections, une collection peut avoir plusieurs invités. Une relation m: n. Cela signifie également que nous devons stocker l'utilisateur contributeur avec l'élément ajouté à la collection.
  4. Ensuite, vous souhaitez stocker les votes positifs. Un utilisateur peut voter pour de nombreux éléments de collection et un élément de collection peut être voté pour de nombreux utilisateurs. m: n encore.

Nous nous retrouvons avec ces tableaux:

  • Utilisateur: identifiant, nom, email, ...
  • Élément: identifiant, nom, description, ...
  • Collection: id, nom, author_user_id
  • Collection_Item: id, collection_id, item_id, user_id
  • Invité: collection_id, invitee_user_id
  • Vote positif: collection_item_id, user_id

Avec ce modèle de données, vous pouvez vérifier si un utilisateur a été invité à une collection et seulement ensuite lui permettre d'annoncer un élément. Si vous vouliez que cela soit assuré par le SGBD, vous devrez changer "Invité" en "Contributeur" et ajouter l'auteur lui-même à ce tableau. Puis changez Upvote.user_id en Upvote.contributor_id et ajoutez une clé étrangère de "Collection_Item" à "Contributor".

0
Thorsten Kettner 15 mars 2021 à 09:00