Disons qu'avec CouchDB, c'est ton code qui est responsable de la structure de tes données.
Avec une couche SQL, c'est normalement à la base de données t'imposer la structure à ton code. Ce qui était particulièrement utile pour les grosses DB centralisées d'entreprise, où chaque service tape dedans à sa guise sans forcément consulter ses petits copains avant. Fut un temps, le SQL était l'interface, et chacun développait dessus. L'utilisateur était développeur, en un sens.
Sauf qu'aujourd'hui, le SQL disparaît de plus en plus derrière des couches d'abstraction, on voit des bases de données servir de manière complètement mono-utilisateur - et je ne parle pas du serveur de DB, mais bien de la DB elle-même : quand une application PHP est la seule à taper sur sa base de données, que le développeur est obligé de faire le grand écart pour conserver une cohérence de schéma entre sa base et son code, on peut légitimement se demander l'intérêt du SQL.
On n'est plus au XXè siècle : le SQL n'est plus une interface frontale, mais tend plutôt à se voir reléguée aux arrière-boutiques. Dans ces conditions, c'est peut-être à la fois une bonne raison et une bonne occasion pour regarder ce qui se fait à côté, non?
[^] # Re: Plus de partie serveur
Posté par Larry Cow . En réponse au journal A quoi peut servir couchdb ?. Évalué à 4.
Avec une couche SQL, c'est normalement à la base de données t'imposer la structure à ton code. Ce qui était particulièrement utile pour les grosses DB centralisées d'entreprise, où chaque service tape dedans à sa guise sans forcément consulter ses petits copains avant. Fut un temps, le SQL était l'interface, et chacun développait dessus. L'utilisateur était développeur, en un sens.
Sauf qu'aujourd'hui, le SQL disparaît de plus en plus derrière des couches d'abstraction, on voit des bases de données servir de manière complètement mono-utilisateur - et je ne parle pas du serveur de DB, mais bien de la DB elle-même : quand une application PHP est la seule à taper sur sa base de données, que le développeur est obligé de faire le grand écart pour conserver une cohérence de schéma entre sa base et son code, on peut légitimement se demander l'intérêt du SQL.
On n'est plus au XXè siècle : le SQL n'est plus une interface frontale, mais tend plutôt à se voir reléguée aux arrière-boutiques. Dans ces conditions, c'est peut-être à la fois une bonne raison et une bonne occasion pour regarder ce qui se fait à côté, non?