Si vous avez suivi l'histoire des trois manifestes, vous savez que fin des années 90s démarre une bataille idéologique sur "la bonne manière" d'intégrer orientation objet et bases de données (lien en commentaire).
Une racine du conflit tient à la nature des données manipulées. En carricaturant, SQL ne supporte que des tables de textes et de nombres. Comment alors représenter des documents, des graphes, des hiérarchies, des pages web, du contenu multimédia ?
La réponse NoSQL ne se fera pas attendre : il nous faut une solution de persistence pour ces données "non structurées".
Le problème c'est que "non structuré" n'est pas un caractère intrinsèque d'une donnée, c'est plutôt un choix (peu) stratégique de celui qui la traite.
En d'autres termes, mettre dans le même pot plein de données de tailles, couleurs et formes différentes, ça caractérise plus le pot-pourri** que ce qu'on y met : le pot est sans contrainte, certes, mais les données ont une structure qu'on décide d'ignorer.
Tout le monde a depuis gobé cette lecture et se réjouit depuis de pouvoir mettre des données "non structurées" en JSON dans ses bases de données "structurées" PostgreSQL. Qui peut le plus, peut le moins.
Plus et moins de quoi exactement ?
De constrainte sur la structure. On en revient à Date & Darwen, c'est une question de type system.
En clair, on peut apprécier un schéma de données Any<Any> tant il rend libre de faire n'importe quoi. A l'inverse, rien n'empêche en théorie de définir un type Ensemble<DocumentHtmlQuiContientLeMotBanane> et de demander au système de base de données de tenir son rôle pour garder les données en ordre. Donc exploitables plus longtemps qu'une oeuvre artistique éphémère.
Long story short : ce n’est pas le modèle relationnel le souci, mais le type system de SQL qui est trop pauvre.
Vous imaginez vous, une db relationnelle avec la richesse du type system de TypeScript par exemple ?
#Databases #History
- Sans manque de respect pour les artistes qui créent de vrais pots-pourris.