Je crois constater à la lecture de cet article qu'une base NoSQL réunit deux conditions:
Une manière non relationnelle de stocker les données,
Un code qui gère ces données libéré de certaines contraintes dues au relationnel.
On voit d'emblée qu'il y a d'autres façons d'articuler ces conditions:
On pourrait imaginer une base relationnelle qui tempère les contraintes de la relation pour privilégier les performances, et accepte un taux de validité faible sur ses données (peut-être qu'il y a des conditions particulières ou cela serait utile).
On peut aussi imaginer utiliser une base relationnelle et y stocker les données en vrac.
Fossil, par exemple, utilise étrangement sa base sqlite: il stocke toutes les données, quelles qu'elles soient, en vrac, dans une unique table. Dans un second temps, il génère, à partir de ces données, des vues en relation les unes avec les autres. De fait, si la structure des vues est cassée, ou doit être changée, il suffit de lancer une commande pour reconstituer celles-ci à partir du vrac. Cf les pages Formats de fichiers de fossil et fossil est une base NoSQL.
# Intervalle entre SQL et NoSQL
Posté par Sygne (site web personnel) . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 5.
Je crois constater à la lecture de cet article qu'une base NoSQL réunit deux conditions:
On voit d'emblée qu'il y a d'autres façons d'articuler ces conditions:
Fossil, par exemple, utilise étrangement sa base sqlite: il stocke toutes les données, quelles qu'elles soient, en vrac, dans une unique table. Dans un second temps, il génère, à partir de ces données, des vues en relation les unes avec les autres. De fait, si la structure des vues est cassée, ou doit être changée, il suffit de lancer une commande pour reconstituer celles-ci à partir du vrac. Cf les pages Formats de fichiers de fossil et fossil est une base NoSQL.