Agrégation de nombreux éléments créés par l'utilisateur en un élément "général"

Question

Je suis en train de créer un site où les utilisateurs peuvent inventorier des éléments et leur appliquer différents attributs, par ex. photos, commentaires, urls, etc.

j'ai une structure de base de données de trois tables: users, entries, associations.

Les tables ont les champs suivants:

utilisateurs
id | joined | email | salt | password

entrées
id | created | creator | type | value

associations
id | created | creator | type | node1 | node2

Voici une ventilation de la fonction du site:

Les utilisateurs d'ajouter des éléments à leur inventaire
Tous les objets créés par l'utilisateur vont dans entries avec un type de « point ». Une ligne est ajoutée à associations avec type 'possession', node1users.id et node2entries.id. Cette ligne d'association est comment je voudrais (en utilisant des entrées INNER JOIN) tirer et afficher l'inventaire d'un utilisateur (pas simplement tirer toutes les entrées où creator = users.id, parce qu'un utilisateur peut créer un élément qu'ils ne possèdent pas).

Ajout d'attributs aux éléments
Cette partie est ce qui semble se débarrasser de tout le monde, j'expliquer les choses. Un "attribut" est vraiment juste un autre élément. De cette façon, il rend fondamentalement une hiérarchie de forme libre créée par l'utilisateur. Par exemple, vous pouvez «tagger» pour qui la cloche avec «Livre», et le livre est un autre élément (que ce soit ou non dans l'inventaire de l'utilisateur ne compte pas). Pour que cela fonctionne, je viens d'ajouter une autre ligne à la table associations avec type 'tag' et node1 entries.id (élément parent) et node2 entries.id ('tag' ou élément enfant). Rappelez-vous qu'une entrée peut également être une url, un commentaire, une photo, etc., cela dépendra simplement de entries.type. Maintenant, je peux tirer tous les attributs d'un élément. Par exemple, toutes les photos: ($ item_id = page que je regarde) "SELECT * FROM entries INNER JOIN associations ON associations.node1 = $item_id AND associations.node2 = entries.id AND entries.type = 'photo'.

Je peux utiliser une requête similaire pour extraire tous les commentaires d'un élément, c'est l'URL, peu importe. Cela me permet de créer un système fluide d'associations entre les articles, les articles et leurs propriétaires, les articles et les commentaires, les commentaires et les commentaires (réponses). Ma question est, une fois que j'ai de nombreuses entrées créées par l'utilisateur d'un élément, par exemple, "MacBook", quelle serait la meilleure façon de fusionner, agréger, fusionner ou quoi que ce soit que vous voulez appeler, tous ces éléments individuels en un seul élément général, de sorte que toutes ces données créées par les utilisateurs peuvent être un morceau de connaissances, si vous voulez. Encore une fois, je ne suis pas si inquiet à propos des utilisateurs qui entrent dans "mac book" "Apple Macbook" etc. En masse, ces utilisateurs ne font que mal et n'affectent pas la communauté.Fondamentalement, si un utilisateur qui ne possédait pas "MacBook" a fait une recherche et a atterri sur la page MacBook, ils verraient les tags les plus populaires, des photos (aléatoire, populaire, peu importe, c'est trivial), des commentaires sur le, URL le plus populaire, etc.

Aussi, merci beaucoup de prendre le temps de lire ma description confuse et élaborée! :)

Answer 1

Avoir une table appelée "Tags", qui aurait un champ Nom unique. Chaque fois qu'un utilisateur entre un nouveau nom, il est ajouté.

Chaque article doit être lié à cette table. Cela ressemble à un grand nombre d'éléments à un arrangement de balise, de sorte que vous n'avez pas besoin d'une table Item_Tags, juste une clé étrangère Tag_Id dans la table Items.

Pour Commentaires, vous avez juste une table de commentaires qui lie à cette table.

Pour afficher seulement 4 photos, vous faites un SELECT de photos qui sont jointes à ce nom (probablement, ils sont des photos de produits qui ont ce nom) et LIMIT 4

Pour d'autres/modèles de conception similaire, faire une recherche pour les questions liées aux tags, comme this one.