Migration MySql datatables aux documents Clodant

Question

Nous prévoyons de passer de MySql à Cloudant NoSQL. Je veux comprendre quelle serait la meilleure approche pour le faire. Nous avons 5 tables différentes - Product (clé primaire ProductId), Issues (clé primaire IssueId, clé Foreign ProductId) et Tags (clé primaire Tag ID, clé Foreign ProductId) et Location (emplacement clé primaire LocationId en tant que clé étrangère avec emplacement dans table de produits) et Policy (clé primaire policyId, IssueId en tant que clé primaire).

Maintenant, nous pensé des deux approches pour le maintien de documents Cloudant.

1. Conserver les documents différents pour chaque ligne avec le type de document unique par table (pour chaque table un seul document les types de documents de type ex comme "produit", "problèmes" tag », "emplacement", "politique").

2. Conserver document différent pour chaque ligne avec toute relation définie dans un seul document (tous les documents de type "produit" que si le maintien de tous les tags, les questions [politiques], emplacement par produit).

qui approche est meilleure?

Answer 1

La réponse dépend vraiment de la taille et du taux de croissance de vos données. Dans SQL- précédente> migrations NoSQL, je l'ai utilisé votre deuxième approche (je ne connais pas votre schéma exact, donc je suppose):

{ 
    _id: "prod1", 
    name: "My product", 
    tags: [ 
    "red", "sport", "new" 
    ], 
    locations: [ 
    { 
     location_id: "55", 
     name: "London", 
     latitude: 51.3, 
     longitude: 0.1 
    } 
    ], 
    issues: [ 
    { 
     issue_id: "466", 
     policy_id: "88", 
     name: "issue name" 
    } 
    ] 
} 

Cette approche vous permet d'obtenir presque tout sur un produit dans un seul appel de l'API Cloudant (GET /products/prod1). Un tel appel vous donnera toutes vos données produit primaires et ce qui aurait été des jointures dans un monde SQL - dans ce cas, des tableaux de choses ou des tableaux d'objets.

Vous pouvez quand même une autre base de données de locations ou policies parce que vous pouvez stocker des informations supplémentaires au sujet de ces objets dans les collections séparées, mais vous pouvez stocker un sous-ensemble de ces données (par exemple le nom et la position géographique de l'emplacement) dans le document produit. Cela signifie dupliquer certaines données de votre collection de "localisations" de référence dans chaque produit, mais cela conduit à une plus grande efficacité au moment de la requête (au prix de compliquer les mises à jour des données).

Tout dépend de la façon dont vous accédez aux données. Pour plus de rapidité et d'efficacité, vous voulez pouvoir récupérer les données dont vous avez besoin pour rendre une page avec le moins d'appels d'API possible. Si vous gardez tout dans sa propre base de données, alors vous devez faire les jointures vous-même, car Cloudant n'a pas de jointures. Cela serait inefficace car vous auriez besoin d'un appel d'API supplémentaire pour chaque "jointure".

Il y a another way to managed "joins" in Cloudant et cela peut convenir si vos collections secondaires sont grandes par exemple si le nombre d'emplacements/d'étiquettes/de problèmes rendrait la taille du document du produit trop grande.