DB Question de conception: Arbre (une table) vs. Deux tables pour les tweets et les retweets?

Question

J'ai entendu dire que les questions et les réponses de stackoverflow sont stockées dans la même table DB.

Si vous deviez créer un service similaire à Twitter, cela ne permettrait qu'un seul niveau de commentaire. c'est-à-dire 1 tweet, puis des commentaires/réponses à ce tweet mais pas de re-commentaires ou de re-réponses.

utiliseriez-vous deux tables pour les tweets et les retweets? ou juste une table où le champ parent_tweet_id est optionnel?

Je sais que c'est une question ouverte, mais quels sont les avantages des deux solutions?

Answer 1

Les retweets sont toujours des tweets normaux. Donc, une table. Vous ne voudriez pas avoir à charger à partir de deux tables pour inclure les retweets.

Answer 2

Avantages d'une table: une manière simple

• Vous pouvez rechercher dans tous les tweets et commentaires.
• Vous pouvez utiliser une colonne identity facilement pour tous les postes.
• Chaque article a le même ensemble de colonnes.

Avantages de deux tables:

• S'il est plus courant pour rechercher ou afficher uniquement les tweets de haut niveau au lieu de tweets + commentaires, la table des tweets est beaucoup plus petit, sans commentaires.
• Deux tables peuvent avoir des ensembles de colonnes différents. Par conséquent, si des colonnes sont significatives pour un type de message mais pas pour l'autre, vous pouvez placer ces colonnes dans la table correspondante sans les laisser vides.
• Les index peuvent également être différents sur deux tables, donc si vous avez besoin de rechercher des commentaires de différentes manières, vous pouvez rendre les index spécialisés à cette tâche.

En bref, cela dépend de la manière dont vous utilisez les données, et pas seulement de leur structure. Vous n'avez pas beaucoup parlé des opérations que vous devez faire avec les données.

Answer 3

Comme toutes les questions de conception, cela dépend. Normalement, je n'aime pas mélanger les concepts dans une seule table. Je trouve qu'il peut rapidement endommager l'intégrité conceptuelle du schéma de base de données. Par exemple, je ne mettrais pas les messages et les réponses dans la même table car ce sont des entités différentes.