Première publication en licence libre du SGBDO EyeDB

Posté par . Modéré par Jaimé Ragnagna.
Tags :
0
30
jan.
2006
Base de données
SYSRA annonce la première distribution publique open source de EyeDB, Système de Gestion de Base de données Orientée Objet (SGBDO) distribué sous licence LGPL.

L'équipe des développeurs de EyeDB fera une présentation de EyeDB à la conférence Objectweb le 31 janvier et sera présente au salon Solutions Linux du 31 janvier au 2 février à Paris (CNIT). Les principales caractéristiques de EyeDB sont : un modèle objet avancé (héritage, collections, tableaux, méthodes, triggers, contraintes, réflexivité), un langage de définition de types basé sur le langage ODL de ODMG, un langage de requête et de manipulation d'objets basé sur le langage OQL de ODMG et des interfaces de programmation C++ et Java.

EyeDB est développé depuis 1993 et a été distribué pour la première fois en 1995 sous licence propriétaire. Il a été utilisé dans le cadre de plusieurs projets de recherche en biologie moléculaire, en collaboration avec le CRI Infobiogen (http://www.infobiogen.fr), Evry, France, et l'Institut Européen de Bioinformatique (http://www.ebi.ac.uk), Cambridge, UK.
  • # utilité ?

    Posté par . Évalué à 7.

    Vous pouvez faire un résumé des avantages d'un SGBDO pour rapport à un SGBDR ?
    Je pense que je ne suis pas le seul à savoir et cela pourrait être certainement utile.
    • [^] # Re: utilité ?

      Posté par (page perso) . Évalué à 4.

      Tu ne manipules plus des enregistrements, mais des objets. Qui peuvent avoir aussi leurs propres méthodes etc.

      En résumé, avec un SGBDOO, plus besoin de ces couches logiciels qui font du mapping relationnel objet. Adieux donc activerecord en ruby et autre truc java super lourd. (bien sûr, il faut le binding langage_de_ton_choix pour le sgbdoo)
      • [^] # Re: utilité ?

        Posté par . Évalué à -1.

        Surtout c'est beaucoup plus rapide quand on manipule des objets, principalement pour les jointures qu'on fait quand on fait du mapping objet-relationnel, la plus besoin.
    • [^] # Re: utilité ?

      Posté par (page perso) . Évalué à 8.

      Ben, l'avantage, c'est qu'une BdD relationnelle n'est pas vraiment adapté au modèle objet...
      - Soit tu raisonnes en SQL, et alors tu fais des requetes et tu génères un objet correspondant,
      - soit tu raisonnes en objet, et là, c'est la galère pour faire le lien avec le SGBDR (enfin, je vois, en Java, si ton objet contient un collection de liens vers d'autres objets, on va dire par exemple une objet Classe qui contient une collection de Profs : le probléme, c'est que ce sont des pointeurs vers les Profs.. Or, tu peux avoir (c'est même sûr) une ou plusieurs autres classes qui ont le même prof... Lorsque tu voudras 'persister' (stocker dans la base), tu devras vérifier si chaque prof existe ou pas, pour ne pas avoir de doublon...)..


      C'est pour ça qu'il y a hibernate, qui fait le lien entre ta conception objet (bien propre objet) et l'implémentation du modèle en relationnel

      http://www.hibernate.org/
      Hibernate offre le lazy-loading, qui permet de récupérer un objet, sans récupérer toute la base !! (sinon en récupérant un objet Classe, on récupère les profs, qui eux mêmes enseignent dans d'autre classes, qui elles mêmes ont d'autres profs.. etc.. tu tires tout d'un coup, en ne voulant qu'un seul élément)

      Le mieux serait d'avoir un système de base de données qui soit lui aussi objet... et ben en voilà une...
      Regarde la doc, elle est bien foutue ( http://www.eyedb.org/quicktour_odl.php )

      Il y a un langage particulier (ODL), qui te permet de representer ta structure d'objet, les héritages, les compositions...


      Bref, tu raisonnes objet, tu programmes objet, et tu stockes objet.
      • [^] # Re: utilité ?

        Posté par . Évalué à 4.

        Qu'est-ce que tu entends par « raisonner objet » ? La seule utilisation d'un SGBD que j'ai vu en langage objet (Java) est par requête SQL via un pilote de BD (JDBC).
        • [^] # Re: utilité ?

          Posté par (page perso) . Évalué à 10.

          Oui, ben justement..

          Pour la persistance, les BdDR ne sont pas vraiment très pratique..
          C'est pour ça que dans java offre la sérialisation...
          Tu as un objet (voir même un vecteur d'objets) et tu as une méthode pour générer un flux de persistance.. Un fichier qui represente tous tes objets, avec la resolution des pointeurs (Je sauvegarde la classe 1ereS, je sauvegarde les profs qu'il y a dedans - Mr Pinchard - Mme Lulu - Mr Gromit - Mr Lampion // je sauvegarde la classe TermS et les profs dedans - Melle Juju - MrGromit (je pointe ici sur celui d'avant !!!) - Mr Pinchard (je pointe sur celui de 1ereS) etc etc-

          En relationnel, tu as la clé NumProf...
          En objet pur, tu pointes sur le Prof...

          Ou alors, si tu veux pas avoir de problème, tu ajoutes le NumProf comme attribut dans la classe Prof...
          Mais c'est pas terrible ! (NumProf, c'est un truc de base de donnée.. Ca n'a rien a faire en vrai, dans l'objet !! C'est de la "pollution", dûe à l'outil que tu utilises pour stocker tes données...)

          Tu vois ce que je veux dire ?
          • [^] # Re: utilité ?

            Posté par (page perso) . Évalué à 7.

            je pense que l'approche que tu exposes pour differencier un modele SQL d'un modele Objet n'est pas des plus pertinant pour des raisons de modelisations.

            Oui, ce que tu exposes permet de montrer à celui qui ne connait pas grand chose aux bases de données ( le cas de beaucoup de monde ) qu'il est possible d'avoir une approche autre avec les données.

            Maintenant, ton exposé contient une lacune :
            - si l'on considere les foreignkeys comme des references symboliques sur des objets dont les attributs sont les attributs du tuple.
            - si l'on fourni deux classes racines l'une modélisation une liste et l'autre un élément de la liste

            alors toute structure découlant d'une requete SQL aussi complexe soit elle sera soit une liste d'élément soit un element représentant un résultat.

            Apres tu dérives par table, chacunes des deux classes racines, et tu as une modélisation qui commence à prendre forme.

            Par contre, là ou le modele SQL et le modele relationnel commence à avoir des lacunes se trouve :
            - sur la fermeture transitive
            - sur un acces navigationnel aux données

            le second point est le simple constat que si l'on connait une information auquel on veut acceder dans ces modeles, il est necessaire de faire une recherche de l'information ( bien que le SQL soit plus permissif que le relationnel, le probleme reste qu'il n'y a pas d'adressage des éléments en tant que tel, uniquement des recherches contraintes ).

            pour le premier point, c'est un peu plus touchy :
            la fermeture transitive est une opération qui retourne l'ensemble des éléments concerrnés de manière récursive "à l'infini" par une requete.
            un exemple concret de cette impossibilité est de sortir l'ensemble d'une discussion threadée avec une opération relationnelle. le seul moyen de contourner cela est de faire appel à d'autres langage que l'algebre relationnelle.

            à contrario, les bases objets fournissent sur ce point des solutions assez elegante.

            A l'inverse, le modele objet dispose lui aussi d'une lacune execrable : l'impossiblité d'agreger les informations, c'est à dire à construire des tables batardes issues de jointures et d'élagage de tables.

            donc le choix d'une base de données doit se faire en sachant ce que l'on va faire avec.
            • [^] # Re: utilité ?

              Posté par (page perso) . Évalué à 4.

              Je n'ai pas compris un traitre mot de ton message. Il n'y a pas un pointeur expliquant plus simplement ce qu'est un SGBDO ? :)
            • [^] # Re: utilité ?

              Posté par (page perso) . Évalué à 5.

              Ca m'a l'air très interessant tout ça, mes quids des évolutions de la base pour suivre l'évolution des dév des classes ?
              Je n'ai pas encore lu la doc (je sais c'est mal), mais ça m'inquete. Dans un SGBDR, c'est découplé, ce qui permet de faire évoluer l'un sans l'autre ou de faire des modifs plus simplement ou plus réalistes quand on a une base avec des tables de plusieurs millions de lignes...
              • [^] # Re: utilité ?

                Posté par . Évalué à 1.

                Ok. merci à tous, c'est un peu plus clair. Pas complètement puisqu'il y a des nuances que je n'ai pas bien assimilés, mais j'irai voir la doc.
              • [^] # Re: utilité ?

                Posté par . Évalué à 2.

                Euh, « découplé »... c'est vite dit je trouve. :)

                Lorsqu'en relationnel tu dois modifier ton schéma, tu dois rajouter des "colonnes" dans tes tables. En objet, ça ne changera pas tellement.

                Et puis, de toute façon, tu es limité par le fait qu'un SGBD est "fortement typé" : varchar(32), c'est pas varchar(31). Ton langage de programmation, qui se situe "au-dessus", n'a pas forcément cette limitation, et tu devras donc par toi-même faire de la logique par-dessus pour gérer ce genre de cas.
            • [^] # Re: utilité ?

              Posté par . Évalué à 3.


              Par contre, là ou le modele SQL et le modele relationnel commence à avoir des lacunes se trouve :
              - sur la fermeture transitive


              Bon, histoire de faire mon chieur :-)
              La fermeture transitive existe en SQL99. Maintenant, je te l'accorde, c'est pas encore tout à fait supporté par tout le monde (et il faut une syntaxe spéciale). De façon générale, même si elle est utile, on peut toujours la simuler à un n-ième niveau.
              • [^] # Re: utilité ?

                Posté par (page perso) . Évalué à 3.

                certes, mais comme j'ai sous entendu : modele relationnel != modele SQL .

                J'ai dans de vieux messages, faisait insidieusement un presqu'amalgame entre relationnel et SQL et plus que je regarde les implems SQL dans le détail et entre autre le SQL99 plus il y a des différences flagrantes.

                la premiere est tres visible :
                - dans un modele relationnel, tout SELECT est en fait un SELECT DISTINCT implicite, ce qui faire qu'il ne peut y avoir de t-uple en doublon, le SQL lui est permissif à ce niveau.

                la seconde qui merite un tres grosse explication avec de l'histoire dedans :
                - le modele relationnel n'a aucun typage, le modele SQL est tres fortement typé et ne peux plus revenir en arriere sur ce point.

                La troisieme est plus subtil et est l'origine de la premiere :
                - tout t-uple doit avoir un ID unique dans l'ensemble de la base au sens du modele relationnel, pour le SQL on s'en fout un peu.

                cet ID unique n'est pas un ID en temps que tel mais doit etre plus considéré comme une signature du t-uple pour l'identifier. cette subitilité ( non codable à l'origine sans overhead colosale ) à introduit cette abération des INDEX unique d'une table. Si l'on regarde attentivement, la notion de formes normales ( surtout la 5ieme et la 6ieme forme normale ), l'on se rend compte que pour construire cet ID, cela necessite que chaque colone soit en fait un systeme clé/valeur en temps que tel.

                pour donner un apercu ( de tres loin et par temps de brouillard ) de la chose :
                ( "col1", "col2", "col3", "col4" )
                ( "a", "b", "c", d")

                le modele SQL stocke cela tel quel, ce qui permet le contenu dupliqué.
                le modele relationnel implique l'unicité des attributs dans chacune des colones puisque chaque colone est en fait un table atomique et que cette "table à 4 colones" est assimilable à une sorte de select codé en dur retournant le contenu ci dessus.


                un exemple plus accesible :

                faire le stockage d'une "table" avec 2 "colones", une contenant une clé unique et l'autre une valeur, est une bete table de hachage. le modele relationnel devrait permettre cela si l'on regarde les kilometres de texte de Date et Codd.

                bizarrement, le modele SQL rajoute à la table un index pour avoir des performances honorables. l'index est une simple table de hachage contenant pour clé, un ID recherché et pour valeur l'adresse du t-uple ... ce qui fait que dans un modele SQL faire une table de hachage revient à rajouter comme overhead ... le moteur SQL lui meme.

                merci au revoir, SQL passe ton chemin.

                Pour en revenir à la fermeture transitive
                que SQL99 essaie tant bien que mal d'expliquer que d'avoir calculer une fermeture transitive permettrait de faire plein de truc cool. il n'empeche que cela necessite de pouvoir resoudre une recherche de type SELECT id_fils FROM arbre WHERE id_pere = ? ; en temps constament constant ( il y a une subtilité dans la formulation ). sinon cela fait partir l'opération dans une panade générale et humiliante pour le systeme ... d'un autre coté avec le point que j'ai évoqué juste avant, je pense que l'on peut imaginer que ce n'est pas pour aujourd'hui que l'on pourra imaginer une implémentation efficace en temps processeur et consommation memoire ( à la rigueur comme pour les INDEX ... perdre du disque pour esperer gagner du temps de lecture sur des table essentiellement en lecture ).
          • [^] # Re: utilité ?

            Posté par . Évalué à 3.

            La sérialisation ne répond qu'à une partie des besoins de la persistence.
            Sa justification initiale serait le support des objets distribués (appel de méthodes à distance avec passage d'objets en paramètre).

            Il existe une autre alternative pour la persistence d'objets dans une application:
            la prévalence, concept qui s'appuie sur la sérialisation mais qui fournit d'autres services:
            http://www.prevayler.org/wiki.jsp
          • [^] # Re: utilité ?

            Posté par . Évalué à 1.

            «Tu vois ce que je veux dire ?»

            Oui, dans l'ensemble. Ce que j'ai lu par la suite me donne à penser qu'on extrait des collections d'objets de la BD au lieu de tables, mais :

            « Le modele objet dispose lui aussi d'une lacune exécrable : l'impossiblité d'agreger les informations, c'est à dire à construire des tables batardes issues de jointures et d'élagage de tables. »

            Ca veut dire qu'on ne peut pas faire de recherche dans la base ?
            • [^] # Re: utilité ?

              Posté par . Évalué à 3.

              Si tu dispose d'un langage de requête l'OQL. tu peux acceder aux donné par un chemin (un peu à la Xpath) ou faire des requêtes qui te permettent de récuperér des objets en fonction de critères. Le problème tient plutôt au fait qu'à la différence de SQL, tu n'as pas de fondements mathématiques derrière.
            • [^] # Re: utilité ?

              Posté par . Évalué à 1.

              Si bien sûr. A quoi sert une base de données si on ne peut pas rechercher dedans ? :-)

              OQL (Object Query Language) permet de faire tout ce que propose SQL, et plus.
      • [^] # Re: utilité ?

        Posté par . Évalué à 2.

        Juste pour être certain Zope ne raisonne pas lui aussi en persistance d'objet avec la ZopeDB?.
        • [^] # Re: utilité ?

          Posté par . Évalué à 1.

          Si si si, ça s'appelle ZODB (Zope Object DataBase), et c'est utilisable en stand-alone. C'est même plus facile d'utilisation AMHA que le binding python de SQLObject...
    • [^] # Re: utilité ?

      Posté par . Évalué à 4.

      Sur l'intérêt et les concepts des SGBDO, voici un document intéressant : http://lbdwww.epfl.ch/f/teaching/courses/poly3/16/16.html .

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

  • # Jamais entendu parler, mais c'est une bonne nouvelle quand même!

    Posté par . Évalué à -10.

    \o/

    "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

  • # Excellente nouvelle

    Posté par (page perso) . Évalué à 5.

    C'est une grande nouvelle ! Les SGBDO sont rares et couteux, voilà enfin un produit libre !
    Ce type de bases de données devrait permettre (dans une certaine mesure) de concevoir et produire des systèmes orientés objet de bout en bout et d'éviter d'avoir à manipuler des outils de mapping Objet/Relationnel.
    Bravo Sysra !
    • [^] # Re: Excellente nouvelle

      Posté par (page perso) . Évalué à 7.

      il s'agit vraiment du premier SGBDO libre
      Ou bien existait-il déjà des alternatives plus ou moins développées ? (mis à part les outils de mapping O/R)
      • [^] # Re: Excellente nouvelle

        Posté par . Évalué à -1.

        il s'agit vraiment du premier SGBDO libre
        Quid de PostgreSQL? A ma connaissance, c'est libre (BSD) et orienté objet. Ou alors, il y a une nuance qui a dû m'échapper!?
        • [^] # Re: Excellente nouvelle

          Posté par (page perso) . Évalué à 2.

          A ma connaissance, Postgres est un SGBDR, pas un SGBDO.
          • [^] # Re: Excellente nouvelle

            Posté par . Évalué à 2.

            A ma connaissance, Postgres est un SGBDR, pas un SGBDO.

            Extrait de la documentation 8.1.2 qui se trouve ici: http://traduc.postgresqlfr.org/pgsql-8.1.2-fr/preface.html#I(...)
            PostgreSQL est un système de gestion de bases de données relationnelles objet (ORDBMS)

            ...D'où ma question que je reprécise: est-ce que EyeDB est le seul SGBDO libre, auquel cas un détail m'a échappé, qui pourrait probablement être lié aux mécanismes internes de ce SGBD? Ou bien est-ce qu'il y a effectivement d'autres SDBDO libres, dont PostgreSQL?
            • [^] # Re: Excellente nouvelle

              Posté par (page perso) . Évalué à 4.

              En fait PostgreSQL est un SGBDR "orienté" objet, en ce sens qu'il te permet notamment de faire de l'héritage entre tes tables, et de définir tes propres méthodes. Par contre la partie accès aux données reste du relationnel, et doit se faire en langage SQL.

              Dans une véritable base objet, les accès sont plutôt du genre :


              identifiant = "trucmuche"
              monobjet = mabase.recupere(identifiant) # va chercher l'objet dans la base
              monobjet.unemethode() # appelle une méthode de cet objet
              monobjet.unepropriete = "blah!" # ici l'objet est modifié, et la base aussi de manière transparente
              • [^] # Définition

                Posté par . Évalué à 3.

                Amusant, nous avons deux définitions différentes de SGBDRO (voir mon message plus bas).
                Me gourre-je, sont-elles complémentaires, ou tous les SGBDRO ne répondraient-ils pas à la même définition (ce qui serait un peu ennuyeux conceptuellement...) ?

                Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

                • [^] # Re: Définition

                  Posté par (page perso) . Évalué à 4.

                  Dans le sens où avec PostgreSQL tu peux aussi définir tes types de données (ce que j'ai oublié de mentionner au dessu), effectivement tu peux stocker des objets dans la base, mais c'est loin d'un accès immédiat et transparent, les manipulations elles-mêmes restent en SQL.

                  Je pense que de toutes façons il vaut mieux utiliser les points forts de chaque type de base de données en fonction de ses besoins, plutôt que de vouloir trouver la base qui répond à tous les besoins, mais dont une partie du code aura sans doute été moins souvent testée en production que les autres (cas des fonctionnalités objet de PostgreSQL, qui est pour le reste carrément balaise et fiable).
                  • [^] # Re: Définition

                    Posté par . Évalué à 1.

                    Merci bien pour l'éclaircissement! :)
                    Effectivement le concept est assez différent et j'ai encore du mal à percevoir les possibilités d'un tel outil (quoiqu'on doit pouvoir faire quelques opérations puissantes).
            • [^] # SGBDO vs SGBDRO

              Posté par . Évalué à 4.

              PostgreSQL est un système de gestion de bases de données relationnelles objet (ORDBMS)

              Soit un SGBDRO, et pas un SGBDO (ODBMS).
              En gros, les SGBDRO sont des SGBDR, donc basés sur le modèle relationnel, qui supportent des objects comme données pouvant être stockées dans les tables, alors que les SGBDO sont basés directement sur le modèle objet.

              J'ai un peu cherché une comparaison entre SGBDO et SGBDRO, et j'ai juste trouvé ça : http://www.ca.com/products/jasmine/analyst/idc/14821E.htm . Intéressant (entre les paragraphes de pub pour leur produit...) mais peut-être pas parfaitement objectif (j'ai plutôt zappé les pubs, mais j'ai comme dans l'idée que leur produit est un SGBDO)...

              Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

            • [^] # Re: Excellente nouvelle

              Posté par . Évalué à 1.

              Attention!

              Les SGBD Relationnal Objets sont differents des SGBD Objets!

              Le Relationnel Objet prend une base relationnelle dans laquelle tu peux stocker des objets avec parfois aussi des procedures (ou methodes) il me semble, et meme de l'heritage (c'est du moins ce que j'avais vu pour Oracle il me semble). Oui Oracle est bien un SGBD Relationnel Objet. Sur les TP que j'avais a faire, la syntaxe de ce genre de choses est vraiement affreuse et difficile a utiliser pour utiliser les references d'objets.
              D'ailleurs, il me semble que SQL3 inclue des bouts de Relationnel Objet. Est-ce que beaucoup de SGBD le supporte? Ca c'est une question pour laquelle je n'ai pas de reponse.

              Tandis qu'un SGBD Objet (que je n'ai jamais utilise) offre un paradigme unique : l'oriente objet. Il n'utilise pas du relationnel avec de l'objet en plus. Mais comme je ne l'ai jamais manipule, je ne sais si c'est tres simple, mais les exemples que j'avais vu semblaient prometteurs! EyeDB va enfin offrir la possibilite d'essayer tout ceci!
      • [^] # Re: Excellente nouvelle

        Posté par . Évalué à 2.

        y a des objet qui ne ressemble pas à des objets et qui en sont la ----------->
        GT.M[tm] is a vetted, industrial strength, transaction processing application platform consisting of a database engine optimized for high TP throughput and a compiler for the M (aka MUMPS) programming language. GT.M is open-source freeware on x86/Linux. It is currently used by the banking industry, health industry, United States Government and many corporations around the world! Now available to users like you through X86 Linux! Although it is console based in Linux, there are programming tools for running the clients on MS WIN in a fully GUI environment.

        Homepage http://www.sanchez-gtm.com/
        Download http://sourceforge.net/projects/sanchez-gtm
        Author Not Shown
        Version 4.3
        Licence GPL
        Source Yes
        Environment Console
        Status Stable


        M'enfin j'dis ça ou aut chose c'est pareil
      • [^] # Re: Excellente nouvelle

        Posté par (page perso) . Évalué à 3.

        il s'agit vraiment du premier SGBDO libre
        Ou bien ...


        Je connaissais db4o [http://db4o.com] qui a une double licence GPL/proprio sur le modèle MySQL.
      • [^] # Re: Excellente nouvelle

        Posté par (page perso) . Évalué à 4.

        Il y en avait déjà d'autres. Personnellement, j'avais jeté un oeil a Ozone il y a presque deux ans (gasp, le temps passe vite) :
        http://www.ozone-db.org/
      • [^] # Autres SGBDO

        Posté par . Évalué à 4.

        Pas encore mentionnés :
        - GOODS ( http://www.garret.ru/~knizhnik/goods.html , supporte C++, C# et Java),
        - PERST ( http://www.garret.ru/~knizhnik/perst.html , supporte Java et C#),
        - DyBase (http://www.garret.ru/~knizhnik/dybase.html , supporte Python, PHP, Ruby et Rebol),
        tous du même auteur (voir http://www.garret.ru/~knizhnik/databases.html où l'on voit qu'il propose aussi des SGBDRO !).

        Note : je ne les ai pas essayés.

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

  • # ZODB ?

    Posté par (page perso) . Évalué à 2.

    Quelqu'un a un comparatif des fonctionnalités de EyeDB comparées à celles de ZODB, la base de données objets intégrée à Zope et libre depuis 1998 (et oui, ça peut s'utiliser SANS Zope) ?
    • [^] # Re: ZODB ?

      Posté par . Évalué à 2.

      A propos de ZoDB,

      il existe une alternative pour python: Durus


      The MEMS Exchange software development team developed Durus after using ZODB successfully for three years. We were very satisfied by the general architecture used by ZODB, but were also aware that much of the complexity of the ZODB source code existed to support features that the MEMS Exchange would never use: most notably the support for multiple threads in a process. Durus is primarily a re-implementation of the subset ZODB architecture that we use for our web applications.


      http://www.python.org/pycon/2005/papers/17/Durus.html
      http://www.mems-exchange.org/software/durus/
  • # performance

    Posté par . Évalué à 0.

    Le pb de toutes ces solutions c'est les performances par rapport à un SGBRD classique tel quel Postgresql (de loin le meilleur serveur SQL à mes yeux). Quand on voit les performances de ZODB (Zope) ...
    • [^] # Re: performance

      Posté par . Évalué à 1.

      trop poilu !
      passera pas
    • [^] # Re: performance

      Posté par (page perso) . Évalué à 0.

      Aucun rapport entre les deux, c'est comme si tu comparais une voiture avec un sandwich.
      • [^] # Re: performance

        Posté par (page perso) . Évalué à 1.

        J'ajouterai que tu peux bien évidemment utiliser une base PostgreSQL depuis Zope, en plus de sa base objets native, tu as donc le meilleur des deux mondes, à utiliser en fonction de tes besoins.
        • [^] # Re: performance

          Posté par . Évalué à 1.

          sauf que Zope + Postgresql c'était pas très au point qd j'avais testé (Zope 2.7 + Psycopg + Postgresql 7.4 à l'époque).
    • [^] # Re: performance

      Posté par (page perso) . Évalué à 1.

      Je serais effectivement intéressé de savoir les performances en accès d'une part, et en mise à jour d'autres parts entre le modèle SGBDR et SGBDO sur une grosse base avec pas mal d'objets/tables liés.

      Heuh pour la comparaison l'utilsiation du modèle SGBDR doit se faire directement, pas via un binding objet sinon la comparaison est faussée.

      Existe-t-il des stats en fonction des implémentations donc ?
  • # Vivement d'autre language de liaison

    Posté par . Évalué à 0.

    ...car seul java et C++, c'est un peut maigre et laisse peu de place au choix.

    Java et C++ sont bien entendu des stars incontournable du monde OO et devaient être dans les premiers languages de liaison pour que cette base touche rapidement de gros projet (si ce n'est pas déjà le cas d'ailleur au vu de son implantation dans le domaine de la biologie...).

    Cependant, aujourd'hui les bases de données sont utilisé dans tous les coins (coin) et accédées par bien des languages objets qui font eux aussi parti des choix technique de projets.

    Bref, vivement donc des liaisons ruby, python, perl, voir même php :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.