Une table vs plusieurs tables

je les tableaux suivants: - messages - fichiers - événements - documentsUne table vs plusieurs tables

Chaque poste, fichier, événement, document peut avoir des commentaires.

Quel est le meilleur schéma de base de données pour cela, et pourquoi?

Première solution

table commentaires (comment_id, author_id, commentaire)
4 tables pour créer des relations (posts_comments (post_id, comment_id), files_comments (file_id, comment_id), events_comments (event_id, comment_id), documents_comments (document_id, comment_id))

Deuxième solution

commentaires Table (comment_id, author_id, commentaire)
items_comments (comment_id, PARENT_TYPE (ENUM [ 'post', 'fichier', 'événement', 'document']), id_parent)

Quelle est la meilleure solution pour cela, ou laquelle de deux devrais-je utiliser?

Source

2012-05-15 Tamás Pap

Je préfère la première solution, être flexible, donc vous devez modifier le fichier de nom des fichiers en éditant 1 nom (si vous voulez), pas tous dans le La table items_comments que vous avez dans la deuxième solution. Als essayer de comprendre la normalisation de la base de données http://en.wikipedia.org/wiki/Database_normalization –

Il peut y avoir de vraies raisons de vouloir/avoir besoin d'une seule table de commentaires. Par exemple, il serait plus simple d'afficher tous les commentaires d'un utilisateur donné. En outre, les recherches à travers tous les commentaires seraient plus simples (mettre un index FTS sur la table et vous avez terminé). Par contre, s'il n'y a pas de raison impérieuse de conserver les commentaires dans une seule table, il existe une troisième solution possible (et plutôt évidente).

Créez un tableau de commentaires séparé pour chaque élément (publication, événement, fichier, document). Les relations RI seraient très simples à définir et à décrire dans cette situation. De plus, si vous tapez très souvent des requêtes ad-hoc, cela pourrait simplifier le processus. Par exemple

select * from documents d left join doc_comments c 
          on d.id = c.docid 
          where d.id=42;

Rien de tout cela ne peut être pertinent ou important pour votre situation, mais cela pourrait valoir la peine d'être considéré. Une pensée aléatoire supplémentaire: Les deux solutions dans l'OP ont le «sentiment» qu'elles définissent une relation plusieurs-à-plusieurs (par exemple, un commentaire peut appartenir à plusieurs éléments). En supposant que ce n'est pas la situation désirée, il peut être évité avec l'index unique approprié, ... mais quand même ... il a cette apparence initiale, ce qui semble conduire à une confusion possible.

Source

2012-05-15 16:27:34

Je préférerais la première solution. Les Sql-Statements sont plus simples ici. Et à mon avis, il est plus conforme à la normalisation de base de données

Source

2012-05-15 14:16:16 Tomtom

Pour être complet, je devrais mentionner une autre possibilité - l'héritage (aka.généralisation ou (sous) hiérarchie des catégories):

enter image description here

Source

2012-05-15 19:52:03

Une table vs plusieurs tables

Répondre

Questions connexes