Il y a beaucoup d'autres conditions dont j'ai entendu parler avec les systèmes non relationnels par rapport aux systèmes relationnels. Je préfère cette terminologie à sql / no-sql car je pense personnellement qu'elle décrit mieux les différences, et plusieurs des serveurs "no-sql" ont des add-ons sql, donc de toute façon ... quel type de modèle de concurrence ou d'isolement de transaction est requis dans votre système. L'une des prétendues différences entre les bases de données rel et non rel est le "cohérent-toujours", "cohérent-principalement" ou "cohérent-éventuellement". Les bases de données relationnelles par défaut entrent généralement dans la catégorie "cohérent-principalement" et avec un peu de travail, et beaucoup de conditions de verrouillage et de concurrence;) peuvent être "cohérents-toujours" pour que tout le monde regarde toujours la représentation la plus correcte d'un donnée donnée. La plupart de ce que j'ai lu/entendu à propos des bases de données non rel, c'est qu'elles sont principalement "cohérentes à terme". Cela signifie qu'il peut y avoir de nombreuses instances de nos données flottantes, de sorte que l'utilisateur "A" peut voir que nous avons 92 widgets dans l'inventaire, tandis que l'utilisateur "B" peut en voir 79, et ils peuvent ne pas être réconciliés tant que quelqu'un ne va pas pour tirer des trucs de l'entrepôt. Un autre problème est la mutabilité des données, à quelle fréquence doivent-elles être mises à jour ? Les bases de données non rel particulières que j'ai été exposées ont plus de frais généraux pour les mises à jour, certaines d'entre elles devant régénérer l'ensemble de données complet pour incorporer les mises à jour.
Maintenant, attention, je pense que non-rel/nosql sont d'excellents outils s'ils correspondent vraiment à votre cas d'utilisation. J'en ai plusieurs que j'étudie maintenant pour des projets que j'ai. Mais vous devez tenir compte de tous les compromis lors de la prise de décision, sinon cela se transformera simplement en un développement davantage axé sur le CV.
