Considérez un modèle pour assortir des clients et des soixantas. Les clients peuvent être à la fois des fournisseurs et des consommateurs de services à différents moments. Les clients peuvent être des individus ou des groupes (entreprises), ce dernier ayant plusieurs contacts. Les contacts peuvent avoir plusieurs adresses, téléphones, e-mails. Certaines de ces relations seront une-à-une (par exemple, le service au fournisseur), mais la plupart seront un à plusieurs ou plusieurs à plusieurs (plusieurs contacts d'une entreprise auraient la même adresse).
Dans ce modèle, plusieurs tableaux associatifs existent généralement, par exemple, client_contact, contrat_addr, contact_phone, contact_euil, service_provider, service_consumer, etc.
Dites que vous émettez une simple requête pour obtenir des informations de contact pour les consommateurs d'un service donné. Outre les six tables d'entité contenant les données, les joinines feraient référence à cinq tables associatives. Rien de particulièrement intéressant à propos de ce type de requête, bien sûr - nous le faisons tous les jours.
Cela m'ont eu lieu: pourquoi ne pas avoir une seule table associative "maître" tenant toutes les associations? Il faudrait que cette table principale ait un "type d'association" en plus des deux PKS, et pour tous les PKS d'être du même type (INTS, GUID, etc.).
D'une part, les requêtes deviendraient plus compliquées car chaque jointure devait spécifier le type et la PK. D'autre part, toutes les jointures accéderaient à la même table, et les performances d'indexng et de mise en cache appropriées pourraient améliorer considérablement.
J'ai supposé qu'il pourrait y avoir un motif (ou un anti-motif) décrivant cette approche, mais n'a rien trouvé en ligne. Quelqu'un a-t-il essayé? Si oui, ça échelle?
Toute références que vous pouvez fournir serait appréciée.
3 Réponses :
Qu'est-ce que vous décrivez me rappelle des tables de fait à partir de l'entreposage de données. Ma compréhension est que vous commencez par un schéma transactionnel typique avec une table pour modéliser toutes les relations à plusieurs à plusieurs. Ensuite, pour restructurer les données pour une analyse dimensionnelle plus facile, vous pouvez regrouper certaines / toutes les relations dans votre schéma dans une table large où chaque colonne est une clé. Cela effectue efficacement toutes les jointures possibles à l'avance et les dépose dans une table, inversant le but de la requête jointes de la relation qui suit pour se rendre aux propriétés de vos entités.
Quoi qu'il en soit, ma compréhension de ce genre de choses est floue et mon expérience efficacement nulle, mais votre idée est peut-être une table de fait par un autre nom, ce qui les rend utiles à enquêter.
Merci DACC, cela me donne un modèle à la recherche et peut peut-être conduire à d'autres. Une recherche rapide a relevé plusieurs articles liés au schéma Star (entreposage) décrivant un "instantané d'accumulation" pour des applications telles que des approbations hypothécaires et des processus de fabrication. Celles-ci ne sont pas parallèles mon modèle, mais le motif a des similitudes et une technique d'utilisation de vues comme alias (tels que les clients, les contacts, les services, etc.) peuvent être utiles. J'ai des temps morts pendant les vacances et je peux mettre quelque chose ensemble pour voir comment cela se comporte. Merci!
Tout d'abord, je pense que vous payez certainement un prix dans la maintenabilité. Chaque fois que j'ai une colonne "type" comme ça, je pense que le drapeau rouge. Il semble susceptible de conduire à des chaînes magiques dans vos procédures - vous devez vous assurer que le type est cohérent entre les inserts et sélectionner, par exemple. Donc, toute augmentation de la performance doit être suffisamment grande pour justifier ce mal de tête.
Deuxièmement, vous payez un prix dans stocker plus de données - la colonne "Type" supplémentaire pour chaque association. Et ensuite, ces données doivent être récupérées lors de la exécution d'une requête, ce qui affecte le nombre de lignes pouvant être en mémoire à la fois (peut-être).
Troisièmement, chaque requête doit probablement accéder au même nombre total de lignes, qu'il s'agisse de stockage dans plusieurs tables ou une. Ainsi, à moins que vous sachiez quelque chose à propos de vos données qui vous permettront de créer des index en cluster ou quelque chose, vous récupérez probablement le même nombre de pages lorsque vous exécutez des questions.
quatrième, les gains de performance probables proviennent de supposer que l'index a un comportement logarithmique et notant que 5log (n) est supérieur au journal (5n), il est donc préférable d'utiliser un grand indice que 5 plus petits. Cependant, l'ajout de la colonne Type va réduire cet avantage. Je ne sais pas vraiment comment analyser si cela l'éliminerait complètement ou simplement le réduire.
Cinquièmement, il semble assez probable que pour au moins certaines requêtes, vous allez finir par rejoindre plusieurs copies de cette énorme table, ce qui semble vraiment être un tueur.
Je serais intéressé de voir quels résultats vous obtenez, mais je serais surpris s'il y a une prestation de performance.
Ceci peut être résolu avec abstraction et héritage de table.
Un client individuel, un client d'organisation, un fournisseur de services sont toutes des parties, qui jouent des rôles.
Une adresse électronique, un numéro de téléphone, une adresse Web et une adresse physique sont toutes des adresses.
Favorited et upéted, comme j'ai eu un intestin, c'est une très mauvaise idée, mais je ne peux pas vraiment identifier la raison exacte (technique). On pourrait faire valoir que vous êtes très très vulnérable aux problèmes de verrouillage avec cette configuration et vous ne pouvez pas réellement ajouter des métadonnées à vos relations à plusieurs à plusieurs. De plus, je supposerais que les RDBM appropriés sont optimisés pour traiter des situations que vous mentionnez dans votre cas.
C'était ma pensée, c'est pourquoi j'ai été surpris de ne pas la trouver documentée comme une très mauvaise idée, du moins là où il y aurait beaucoup de crud. Je soupçonne avec des volumes basse TX et où les requêtes pouvaient vivre avec une isolation faible, elle pourrait être viable. J'avais supposé que la table unique «maître» pourrait donner de meilleures optimisations, mais cela pourrait dépendre des SGBD spécifiques. La comparaison des plans (avec «maître» vs. Reguar Assoc's) serait instructif.
Je pense que le type de réflexion deviendrait la partie supérieure de l'ordre de la clé ou des index, donc jointures serait quelque chose comme: sur type = 'type1' et pk1 = pk2? La performance sera-t-elle vraiment meilleure dans ce cas?