Comment savoir quelle est la conception de base de données la plus appropriée? (auteurs, articles et commentaires)

Question

Supposons une base de données avec trois tables: Author, Articles, Comments

Si l'on suppose que la relation est la suivante:

Author has many Articles 
Article belongs to one Author 
Article has many Comments 
Comment belongs to one Article 

Si je veux savoir quel auteur écrit le plus article commenté, je dois d'abord sélectionner tous les articles qui appartiennent à un auteur spécifique. Ensuite, je peux compter le nombre de commentaires qui ont été postés sous chacun de ces articles. Qui en général conduit à des requêtes plus complexes.

Si les relations sont les suivantes:

Author has many Articles 
Article belongs to one Author 
Article has many Comments 
Comment belongs to one Article 
**Comment belongs to one Author of the relevant Article** 

alors je pourrais sélectionner directement et compter tous les commentaires qui ont été affichés dans les articles d'un auteur particulier, sans se soucier, y compris les articles dans la requête.

Mais cela implique une relation redondante. Au regard des meilleures pratiques de performance, d'utilisabilité et de codage, quelle est la meilleure approche? Je me souviens d'avoir lu quelque part, que l'on devrait utiliser seulement la première approche, et éviter les relations redondantes. Mais je ne me souviens pas où ou pourquoi. Qu'est-ce qu'un lien vers une approche scientifique pour répondre à cette question?

Answer 1

Votre première approche est une conception normalisée. Ce devrait être la valeur par défaut - c'est plus maintenable, moins sujette aux erreurs, et nécessite moins de code global.

La deuxième option est une conception dénormalisée. Si vous y réfléchissez, il vous faudra trouver l'auteur de l'article chaque fois que quelqu'un publie un commentaire, et incrémenter le champ "commentaires"; c'est probablement plus de code, et rend l'écriture plus lente. Cela signifie également qu'un simple bogue dans votre code "créer un commentaire" pourrait casser la logique de l'application, et vous devrez probablement créer une transaction pour chaque action "écriture" afin que vous puissiez garantir que le commentaire et la mise à jour de "authors.comment" réussit ou échoue. Ainsi, la deuxième option est nettement plus complexe et plus lente pour écrire des commentaires.Il peut être plus rapide pour l'interrogation, mais comme vous rejoindrez les clés primaires, vous ne pourrez certainement pas mesurer cet impact sur les performances avant d'avoir atteint une taille de base de données de centaines de millions d'enregistrements.

En général, je recommande l'approche suivante; prenez chaque étape seulement si les étapes précédentes ne vous ont pas donné assez de performance.

• concevoir un modèle relationnel.
• air que bases de données relationnelles (index, etc.)
• améliorer le matériel - RAM, CPU, disques SSD etc.
• créer une plate-forme de mesure afin que vous puissiez identifier les défis de performance et expériences menées. Créer des benchmarks basés sur les tailles de données actuelles et attendues; trouvez un moyen de remplir votre plate-forme de test avec des données factices jusqu'à ce que vous ayez le volume de données dont vous avez besoin pour évoluer.
• lancez vos requêtes sur le banc d'essai. Assurez-vous qu'il n'y a pas d'autres ajustements de performance de l'indexation ou de l'optimisation des requêtes.
• introduire la mise en cache au niveau de l'application. Dans votre exemple, la mise en cache du nombre de commentaires pour un auteur pendant 1 heure peut être acceptable.
• dé-normaliser votre schéma. Utilisez votre banc d'essai pour prouver qu'il vous donne les performances que vous attendez.
• chercher des solutions de données plus exotiques - sharding, les données de partitionnement etc.

dénormalisation est si loin de la ligne, car il présente des risques réels de maintenance, rend plus complexe votre code beaucoup, et est loin d'être aussi efficace que l'ajout de 4 Go supplémentaires à votre serveur dans la plupart des cas.

Answer 2

"Mais je ne me souviens pas où ou pourquoi? S'il vous plaît lien vers une approche scientifique pour répondre à cette question."

La «démarche scientifique» est l'ensemble du corps de la théorie de la normalisation.

La "relation redondante" crée un problème supplémentaire dans l'application de l'intégrité. Le système doit s'assurer que la relation commentaire/auteur telle que spécifiée par un utilisateur mettant à jour la base de données est la même que celle impliquée par les relations commentaire/article et article/auteur. Il s'agit d'un problème de complexité supplémentaire pour le système lors de l'application de l'intégrité des données et un problème de complexité supplémentaire pour les utilisateurs effectuant la mise à jour afin de garantir qu'ils ne spécifieront pas les mises à jour non valides. Ainsi, votre «seconde approche» pourrait rendre l'interrogation «plus simple», mais au prix de créer des complexités supplémentaires du côté «mise à jour».

Answer 3

Les tables représentent les relations d'affaires/application (ship) s/associations. Comme dans le relationnel modèle & entité-relation modélisation. Chaque résultat de requête contient les lignes de valeurs liées par une relation commerciale exprimée par l'expression de la requête. Vos "relations" [sic] sont des FK (clés étrangères).

Ce sont des contraintes - des affirmations vraies dans toutes les situations de l'entreprise - disant que si certaines valeurs sont liées par une certaine relation d'affaires, elles sont également liées par une autre. Mais les FK ne sont ni nécessaires ni suffisants pour utiliser la base de données - pour l'interpréter ou la mettre à jour. Ils contraignent l'état de la base de données, mais ils ne vous disent pas ce qu'il contient.

Vos relations d'affaires & tables correspondantes sont en fait comme:

Author authored Article 
Commenter commented Comment re Article 

Un tel modèle de déclaration indiquant une relation d'affaires est son (caractéristique) prédicat.Pour interroger l'utilisation de ces il n'a pas d'importance quelles sont les contraintes - si vous voulez que les auteurs qui ont formulé des commentaires sur les articles rédigés par eux-mêmes qui est

/* rows where 
FOR SOME a.* & cr.*, 
     Author = a.Author 
    AND a.Author authored a.Article 
    AND cr.Commenter commented cr.Comment re cr.Article 
    AND a.Author = cr.Commenter 
*/ 
select Author 
from authored a join commented_re cr on a.Author = cr.Commenter 

quelle que soit si un auteur peut éditer plusieurs articles ou plusieurs les auteurs peuvent écrire un article, ou plusieurs auteurs peuvent écrire plusieurs articles, ou les commentateurs peuvent commenter re plusieurs commentaires, etc., ou les commentateurs peuvent commenter plusieurs articles, etc, ou un commentaire peut être plusieurs articles, etc., ou les auteurs peuvent commenter, ou les commentateurs peuvent écrire, ou les commentateurs peuvent seulement commenter les articles qu'ils ont créés (une contrainte FK) ou les auteurs nommés 'henk' peuvent commenter au maximum 7 articles, ou toute contrainte.

Normalization remplace une table par selects de celui-ci qui join revenir, ce qui est la même chose que dire qu'il remplace une relation d'affaires qui est exprimable par un AND par d'autres qui sont exprimable par les expressions qui ont été AND ed. Il arrive que si auteur ne peut écrire un article et un article ne peut être écrit par un auteur puis le AND/join tableau ci-dessus pourrait (en fonction d'autres choses) être une bonne conception, mais sinon il pas être un bon design, et devrait être remplacé par les tables séparées. FDs & d'autres contraintes sont l'expression basée sur la table post-conception des règles métier correspondantes qui découlent des relations d'affaires choisies & quelles situations commerciales peuvent survenir. Donc, votre «approche scientifique» est la modélisation d'informations relationnelles et la conception de base de données, y compris la normalisation.