Quand incorporer ou référencer des données
Dans l’unité précédente, nous avons incorporé les données d’adresse du client et de mot de passe dans un nouveau document customer. Ce processus réduit le nombre de requêtes, ce qui améliore les performances et réduit les coûts. Pourtant, vous ne pouvez pas toujours incorporer des données. Il existe des règles qui déterminent quand vous devez incorporer des données dans un document au lieu de les référencer dans une autre ligne.
Quand est-il préférable d’incorporer des données ?
Incorporez des données dans un document quand les critères suivants s’appliquent à vos données :
- Données lues ou mises à jour ensemble : les données lues ou mises à jour ensemble sont presque toujours modélisées sous forme de document unique. Cela réduit le nombre de demandes, ce qui correspond à notre objectif d’efficacité. Dans notre scénario, toutes les entités Customer sont lues ou écrites ensemble.
- Relation un-à-un : par exemple, Customer et CustomerPassword ont une relation un-à-un.
- Relation un-à-quelques-uns : dans une base de données NoSQL, il est nécessaire de séparer les relations un-à-plusieurs en deux catégories, limitées ou illimitées. Customer et CustomerAddress correspondent à une relation un-à-plusieurs limitée, car les clients d’une application d’e-commerce ont, en temps normal, un nombre peu élevé d’adresses d’expédition. Quand la relation est limitée, il s’agit d’une relation un-à-quelques-uns.
Quand est-il préférable de référencer des données ?
Référencez les données sous forme de documents distincts quand les critères suivants s’appliquent à vos données :
Lecture ou mise à jour indépendante : Cela est particulièrement vrai lorsque vous combinez des entités qui aboutiraient à des documents de grande taille. Les mises à jour dans Azure Cosmos DB nécessitent le remplacement de l’élément dans sa totalité. Si un document comporte quelques propriétés fréquemment mises à jour et un grand nombre de propriétés principalement statiques, il est beaucoup plus efficace de diviser le document en deux. Un premier document contient alors le plus petit ensemble de propriétés, celles fréquemment mises à jour. L’autre document contient les valeurs statiques qui ne changent pas.
Relation un-à-plusieurs : cela est particulièrement vrai si la relation est illimitée. Si vous avez un document qui augmente en taille x fois, le coût et la latence de ces mises à jour continueront d’augmenter. Cela est dû à la taille croissante de la mise à jour qui coûte plus de RU/s et aux charges utiles qui passent sur le réseau, ce qui, en soi, est également inefficace.
Relation plusieurs-à-plusieurs : nous verrons un exemple de ce type de relation dans une unité ultérieure avec des étiquettes de produit.
Séparer ces propriétés réduit la consommation de débit pour une plus grande efficacité. Cela réduit également la latence pour de meilleures performances.