Finalement, la cohérence signifie que les changements prennent du temps à se propager et que les données peuvent ne pas être dans le même état après chaque action, même pour des actions ou des transformations identiques des données. Cela peut entraîner de très mauvaises choses lorsque les gens ne savent pas ce qu'ils font lorsqu'ils interagissent avec un tel système.
Veuillez ne pas mettre en œuvre des magasins de données de documents critiques pour l'entreprise tant que vous n'avez pas bien compris ce concept. Il est beaucoup plus difficile de réparer une implémentation de magasin de données de document qu'un modèle relationnel, car les choses fondamentales qui vont être gâchées ne peuvent tout simplement pas être corrigées car les choses nécessaires pour le réparer ne sont tout simplement pas présentes dans l'écosystème. La refactorisation des données d'un magasin en vol est également beaucoup plus difficile que les simples transformations ETL d'un SGBDR.
Tous les magasins de documents ne sont pas créés égaux. Certains de nos jours (MongoDB) prennent en charge des transactions d'une sorte, mais la migration des banques de données est probablement comparable aux frais de réimplémentation.
AVERTISSEMENT: Les développeurs et même les architectes qui ne connaissent pas ou ne comprennent pas la technologie d'un magasin de données documentaires et qui ont peur de l'admettre par peur de perdre leur emploi mais qui ont été classiquement formés au SGBDR et qui ne connaissent que les systèmes ACID (à quel point cela peut-il être différent ?) et qui ne connaissent pas la technologie ou prennent le temps de l'apprendre, manqueront de concevoir un magasin de données de document. Ils peuvent également essayer de l'utiliser comme SGBDR ou pour des choses comme la mise en cache. Ils décomposeront ce qui devrait être des transactions atomiques qui devraient opérer sur un document entier en morceaux «relationnels» en oubliant que la réplication et la latence sont des choses, ou pire encore, en entraînant des systèmes tiers dans une «transaction». Ils le feront pour que leur SGBDR puisse refléter leur lac de données, sans se soucier de savoir si cela fonctionnera ou non, et sans test, car ils savent ce qu'ils font. Ensuite, ils agiront surpris lorsque des objets complexes stockés dans des documents séparés tels que des «commandes» ont moins «d'articles de commande» que prévu, ou peut-être pas du tout. Mais cela n'arrivera pas souvent, ni assez souvent pour qu'ils avancent simplement. Ils peuvent même ne pas toucher le problème du développement. Ensuite, plutôt que de repenser les choses, ils lanceront des «retards», des «tentatives» et des «vérifications» pour simuler un modèle de données relationnel, ce qui ne fonctionnera pas, mais ajoutera de la complexité supplémentaire sans aucun avantage. Mais il est trop tard maintenant - la chose a été déployée et maintenant l'entreprise fonctionne dessus. Finalement, le système entier sera jeté et le département sera externalisé et quelqu'un d'autre le maintiendra. Cela ne fonctionnera toujours pas correctement, mais ils peuvent échouer moins cher que l'échec actuel.