Avantages des données de modélisation dans une table par rapport à l'aide de deux tables

Question

En supposant que vous modélisez un Q & Une base de données en utilisant MySQL, je suis au courant de deux façons d'aborder l'architecture du modèle:

1. Créer une seule table pour les questions et réponses avec un "typeId"
2. Créez deux tables séparées; une pour les questions et une des réponses

Quelqu'un peut-il élaborer sur les avantages et les inconvénients des deux approches, et pourquoi utiliser une approche sur l'autre?

Mes propres observations:

1. approche 2 est plus normalisée
2. approche 2 nécessite deux "commentaires" pour tables de Q et A ou de une seule table avec composite PKs; (Q de & mai ID identiques de A)
3. approche 1 peut devenir très compliquée avec auto-jointures et ainsi de suite

Answer 1

Le spécifique de la conception dépend vraiment de vos besoins et ce que vous voulez atteindre et comment énorme base de données serait.

approche 1 table: Vous pouvez être en mesure d'utiliser une seule table dans le cas où vous fournissez uniquement/permettent une réponse par question (à la FAQ), où vous n'avez id,question,answer champs et les questions sont pas ajouté à DB jusqu'à ce que la réponse soit donnée, ou mettre à jour la ligne quand la réponse est disponible.

2-table approche: Dès qu'il peut y avoir plus d'une réponse/commentaire par question. Je pourrais choisir un modèle un peu différent de celui de @ Spredzy car j'inclurais tout comme les "emails": message_id, in_reply_to, timestamp, text pour plus de simplicité. Cette simplicité ne vous permettra pas d'étiqueter spécifique (réponses VS commentaires à moins qu'une seule réponse et in_reply_to répondre devient commentaires comme sur SO). Les questions sont celles avec in_reply_to IS NULL.

3/approche plus table: Si vous voulez vraiment des performances en ayant une longueur fixe-ligne sur la table principale et ne pas besoin d'afficher un extrait de questions et de réponses, mais veulent seulement savoir les numéros. Vous sépareriez le texte, les pièces jointes, etc. Ou simplement parce que vous voudriez éviter les jointures de soi comme suggéré par @orangepips: " Enfin, les jointures de soi sucent et présentent un excellent moyen de tuer la performance." ") et ont séparé tables pour tout.

Answer 2

Modèle cela comme deux tables. Les questions peuvent avoir plus d'une réponse. Créez des tables de commentaires séparées pour les questions et réponses. J'imagine que le cas d'utilisation le plus probable ne voit pas les données de commentaire se mélanger dans une seule instruction DML. Une seule table distinguée par une colonne de type peut être utile si vous représentez l'héritage d'un modèle objet, mais ce n'est pas le cas ici. En outre, l'intention de la table est brouillée pour quiconque examine le schéma, car il aurait besoin de connaître les possibilités énumérées pour le type; pourrait être une table de recherche que je suppose, mais pour deux possibilités - et pas plus - semble être une perte.

Enfin, les jointures auto aspirent et présentent un excellent moyen de tuer les performances.

Answer 3

Je voudrais créer 2 tables:

Celui qui représente la question, réponse et commentaires. Si vous regardez attentivement, ils ont les mêmes données de base: user_id, text, date, plus un champ type_id et tous les autres champs dont vous pourriez avoir besoin.

L'autre table serait une table assez simple: le type

type_id type_desc 
xxx-x-xx question 
xxx-x-xx answer 
xxx-x-xx comment 

En faisant cela, votre modèle sera hautement évolutive, plus rapide sans duplication des données (normalisation). Enfin, techniquement parler pour obtenir toute la question ou toute la réponse d'une question c'est juste une simple jointure.

espère que cela pourrait aider,

Answer 4

Une table par type de données. Si les questions et les réponses sont identiques (comme si les objets dans la POO), une table suffit. Sinon, non.

Un seul tableau de commentaires avec PK composites est correct car les commentaires sont toujours d'un type d'objet: Commentaire. Le fait qu'ils puissent référencer à la fois les Q et les A n'affecte pas cela.