J'essaie de comprendre comment implémenter cela pour mon système ... et de sortir de la tête de l'espace SDBMS pour l'instant ...
Une partie de mon dB actuel a trois tables: spectacle, showentry et entrée. Fondamentalement, la showentrie est une table de jonction à plusieurs à plusieurs entre exposition et entrée. Dans ma pensée RDBMS, il est assez logique car toute modification permettant de montrer des détails peut être effectuée au même endroit, et la même avec l'entrée.
Quel est le meilleur moyen de le refléter dans un stockage basé sur un document? Je suis sûr qu'il n'y a aucune façon de le faire, mais je ne peux pas m'empêcher de penser que si le stockage basé sur des documents est approprié pour ce cas.
FYI, je envisage actuellement de mettre en œuvre Ravendb. Alors que les discussions sur la conception générale de la NOSQL seront bonnes, une plus grande Ravendb est fantastique!
merci, Ré.
3 Réponses :
Lors de la modélisation d'une relation nombreuses à plusieurs dans une base de données de documents, vous stockez généralement une collection de clés étrangères dans un seul des documents. Le document que vous choisissez dépend en grande partie de la direction que vous avez l'intention de traverser la relation. Traversant en une solution est trivial, traversant l'autre solution nécessite un index.
Prenez l'exemple de panier. Il est plus important de savoir exactement quels articles sont dans un panier particulier que quels paniers contiennent un élément particulier. Étant donné que nous suivons généralement la relation dans la direction du panier à l'item, il est plus logique de stocker des ID d'article dans un panier qu'il ne contient de stocker des ID du panier dans un article.
Vous pouvez toujours traverser la relation dans la direction opposée (par exemple, trouver des paniers contenant un élément particulier) à l'aide d'un index, mais l'index sera mis à jour en arrière-plan afin qu'il ne soit pas toujours précis à 100%. (Vous pouvez attendre que l'index devienne précis avec Si vous avez besoin d'une précision immédiate de 100% dans les deux sens, vous pouvez stocker des clés étrangères dans les deux documents, mais votre demande devra mettre à jour deux documents chaque fois qu'une relation est créée ou détruite. waitfornonstaleresults , mais ce retard montrera dans votre assurance-emploi.)
Merci - grande explication. Je suis allé avec une combinaison de stocker des clés étrangères de chaque côté, ainsi que d'un côté uniquement pour une relation. La fréquence de mon interface utilisateur accédant à la relation dans chaque direction est à peu près la clé.
Les relations à plusieurs à plusieurs dans NOSQL sont implémentées via une gamme de références sur l'une des entités.
Vous avez deux options:
L'emplacement de la matrice est déterminé par la direction la plus commune d'interrogation. Pour résoudre les enregistrements dans l'autre direction - Index, le tableau (dans Ravendb, cela fonctionne comme un charme).
Habituellement, avoir deux tableaux sur les deux entités pointant les uns aux autres apportent plus de chagrin que la joie. Vous perdez la source unique de la vérité dans un environnement cohérent ... il a un potentiel pour casser l'intégrité des données.
Consultez cet article - relations entité dans NOSQL (un à plusieurs, plusieurs à plusieurs) . Il couvre les relations d'entité de divers angles, en tenant compte des performances, des coûts opérationnels, des temps / des coûts de développement et de maintenance ... et fournit des exemples pour Ravendb.
show a une matrice d'entrée éléments;
entrée a une matrice de Afficher s.