J'ai entendu parler d'un projet utilisant la technologie REST, de XML. Alors, je vais y aller de mon point de vue.
Je n'avais jamais entendu parler de couchDB, je pense que je me documenterai rapidement à son sujet. Par contre, je pratique un peu la philosophie REST + XML sur mon projet actuel, et pour peu que ça se rapproche un minimum du sujet du journal, voici ce que j'en pense...
Le projet, c'est une application web. On récupère des flux en entrée, on en affiche un formatage à l'écran, l'utilisateur les enrichit éventuellement, on crache un flux en sortie. En gros, c'est juste un projet informatique de SSII.
L'architecture nous a imposé de faire du REST, avec un SILO (partie données) et un PILOTE (IHM / BATCHs). Les données transitant entre les deux sont un flux ATOM / xHTML. Voilà pour le contexte.
Dans la pratique, on a une base de données MySQL qui stocke les ATOM dans un champ BLOB, avec une colonne idtech et une autre dateMiseAJour. Basta. On souhaite faire évoluer le modèle de données? Aucun problème de changement de modèle à coups d'ALTER TABLE. La reprise de données? De toute manières, on est plus ou moins obligé d'utiliser un langage de haut niveau, on peut donc appliquer des règles métier évoluées sans "trop" s'embêter (XML parsing inside, SQL souvent insuffisant). Voilà pour les avantages.
En ce qui concerne les inconvénients, on retrouve une complexité accrue à mettre en place des objets métier (avec getter et setter par champ; toutes les données étant gérées dans du XML, beaucoup de xPath, pas mal de DOM; technologie peu maîtrisée (uniquement sur le projet???)). Et puis en général, qui dit IHM dit tris ou rechercher. On se retrouve donc peu à peu à "externaliser du BLOB" certains champs xPath dans des colonnes de la base de données. D'où duplication d'information, difficulté accrue à maintenir la cohérence des données qui sont dupliquées, etc.
J'y vois effectivement une grosse plu-value quant l'objectif de l'application utilisant cette base de données est principalement de restituer des données, peu modifiées. Il suffit alors de faire un select, une petite XSL, et c'est tout.
En espérant que ce que j'ai raconté ait un quelconque intérêt et / ou rapport avec la choucroute...
[^] # Re: Plus de partie serveur
Posté par yapoc . En réponse au journal A quoi peut servir couchdb ?. Évalué à 4.
Je n'avais jamais entendu parler de couchDB, je pense que je me documenterai rapidement à son sujet. Par contre, je pratique un peu la philosophie REST + XML sur mon projet actuel, et pour peu que ça se rapproche un minimum du sujet du journal, voici ce que j'en pense...
Le projet, c'est une application web. On récupère des flux en entrée, on en affiche un formatage à l'écran, l'utilisateur les enrichit éventuellement, on crache un flux en sortie. En gros, c'est juste un projet informatique de SSII.
L'architecture nous a imposé de faire du REST, avec un SILO (partie données) et un PILOTE (IHM / BATCHs). Les données transitant entre les deux sont un flux ATOM / xHTML. Voilà pour le contexte.
Dans la pratique, on a une base de données MySQL qui stocke les ATOM dans un champ BLOB, avec une colonne idtech et une autre dateMiseAJour. Basta. On souhaite faire évoluer le modèle de données? Aucun problème de changement de modèle à coups d'ALTER TABLE. La reprise de données? De toute manières, on est plus ou moins obligé d'utiliser un langage de haut niveau, on peut donc appliquer des règles métier évoluées sans "trop" s'embêter (XML parsing inside, SQL souvent insuffisant). Voilà pour les avantages.
En ce qui concerne les inconvénients, on retrouve une complexité accrue à mettre en place des objets métier (avec getter et setter par champ; toutes les données étant gérées dans du XML, beaucoup de xPath, pas mal de DOM; technologie peu maîtrisée (uniquement sur le projet???)). Et puis en général, qui dit IHM dit tris ou rechercher. On se retrouve donc peu à peu à "externaliser du BLOB" certains champs xPath dans des colonnes de la base de données. D'où duplication d'information, difficulté accrue à maintenir la cohérence des données qui sont dupliquées, etc.
J'y vois effectivement une grosse plu-value quant l'objectif de l'application utilisant cette base de données est principalement de restituer des données, peu modifiées. Il suffit alors de faire un select, une petite XSL, et c'est tout.
En espérant que ce que j'ai raconté ait un quelconque intérêt et / ou rapport avec la choucroute...