ZODB et/ou SGBDR

Voici une petite question (qui va en faire réagir plus d'un ? ) pour démarrer ce forum ! J'ai entendu plusieurs fois les communes se plaindre de ne pouvoir accéder aux données contenues dans les bases de données de leurs applications "métier" (afin de les réutiliser dans une application tierse). Je me pose dès lors la question : ne vaut-il pas mieux développer des applications Plone qui n'utilisent pas uniquement la ZODB mais stockent une partie des données (le contenu réutilisable) dans une SGBDR classique ? Les communes qui développent elles-même répondront sanas doute qu'elles peuvent accéder via python ou autre à leurs données de l'extérieur de Zope. Mais qu'en sera-t-il des communes qui n'auront pas les compétences en Zope/Plone, utiliseront une application de la communauté et voudront consulter les données enregistrées par l'application (pour les afficher dans leur intranet PHP par exemple) ? Qu'en est-il de l'interopérabilité si tout est dans la zodb ? A vos claviers !

Dans le cas de la réutilisation des données par une autre application ou pour établir des statistiques, ou pour toute autre raison qui nécessiterait un accès "SQL" aux données, il est très "facile" de substituer la ZODB par une base de donnée relationnelle (PostGreSQL par exemple) via l'utilisation de l'attribut "storage" dans Archetypes et, par exemple à nouveau, du connecteur zPsycopgda qui est un connecteur PostGreSQL pour Zope très abouti (peut-être le plus abouti actuellement). Cela dit, il faut savoir que l'intérêt de la ZODB est qu'on laisse de côté le concept "stockage", le système s'en charge pour le développeur. Si on souhaite stocker dans un SGBDR, il faut bien réfléchir à l'utilité d'une telle pratique. De plus, si on a commencé avec un produit ZODB, il y a moyen, soit de migrer vers du SQL au besoin, soit d'écrire des scripts python qui permettent d'afficher les données nécessaires et de réaliser les requêtes souhaitées. Donc, en gros, SGBDR toujours possible, mais bien vérifier l'utilité du relationnel dans son application. Il faut donc savoir que presque tout est possible en Zope/Plone, d'ailleurs, et à des fins de statistiques, notre ancien système de gestion des commerçants utilisait un SGBDR PostGreSQL. Le nouveau produit "commerçants" (développé en collaboration avec l'ISIPS, merci Alain Meurant) intégrera probablement le choix de l'utilisation ou non d'un SGBDR ou de la ZODB. BASTIEN Gauthier.

Un produit permet de substituer la ZODB par un SGBD comme Postgres, MySQL ou Ingres : APE (Adaptable Persistence Engine). N'oublions toutefois pas que l'organisation d'une base de données relationnelle est différent de celle d'un BD orientée object. Bon courage pour écrire les commandes SQL permettant de retrouver des objets dans les tables ! (http://plone.org/products/ape)

A titre informatif, il semblerait qu'APE ai évolué vers un nouveau produit appelé PGStorage (pour PostGreSQL Storage). C'est Godefroid Chapelle qui me parlait de ce projet hier (1 mars 2006). Shane Hathaway, le développeur d'APE présente sur son site http://hathawaymix.org/ et notamment via son Blog http://hathawaymix.org/Weblog/2006-02-11 ce nouveau produit. Le but est de "remplacer" la ZODB par une base de données SQL. A priori pas vraiment pour pouvoir profiter du SQL directement dans Zope, les tables créées étant trop complexes, mais parce que PostGreSQL semble plus rapide et adaptable que la ZODB. Il semblerait également que ce produit soit plus efficace que ZEO (le système de load balancing de Zope). A suivre dès lors je pense, même si certains aspects de PGSQL (tel que le stockage de Binary Large Objects ou BLOBs) ne sont pas encore suffisamment orienté stockage d'objet comme l'est la ZODB. De toutes façons, si le système, qui est toujours en test actuellement, est vraiment intéressant, il sera adapté voire intégré dans les prochaines versions de Zope. Bien qu'il ne soit encore testé qu'avec Zope2, il semblerait en effet que Zope3 puisse profiter de ce type de stockage. Une version est déjà disponible en téléchargement : http://hathawaymix.org/Software/PGStorage Gauthier.

Est-ce vraiment la question ?? Le problème des bases développées par nos amis fournisseurs n'est pas tant les données que le format des tables et dans le cas de WGH, le redondance des données dans plusieurs tables sans véritable synchronisation, ici je ne vois pas où est vraiment l'avantage, de toute façons qui pourra pondre les requètes SQL ?? Si les gens ne savent pas extraire leurs données d'un SGDBR X , je ne vois pas comment ils feront avec un SGDBR Y just my 2 ¢