samedi 06 septembre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[22] Tiny Accounting : nouveau logiciel de comptabilité
[19] Sortie de Scribus 1.3.2
[9] grabslides 1.00 est sorti
[31] Annonce de Samba 4 Technology Preview
[21] Wormux 0.7 beta3
[20] Toujours à propos de scanner 3D...
[162] Sortie de Bible Desktop 1.0
[26] Klive, pour faire partager la version de son noyau et plein d'autres choses
[26] Mondorescue 2.06
[31] Le codec vidéo libre XviD 1.1.0 est disponible

Liens connexes

Téléchargement (1310 hits)

Dépêche modérée par

Ragnagna

Dépêche éditée par

jerome_misc

Logiciel : Première publication en licence libre du SGBDO EyeDB

Posté par Déchelle François (). Modéré le 30 janvier 2006.

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).

Téléchargement (1310 hits)

> Lire la suite (45 commentaires, moyenne: 2,6). [dépêche : 715 caractères]

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.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

utilité ?

Posté par dark_moule () le 30/01/2006 à 11:00. (lien). É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 Laurent J (page perso, ) le 30/01/2006 à 12:00. (lien). É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 neil () le 31/01/2006 à 08:54. (lien). É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 sylvain cherrier (page perso, ) le 30/01/2006 à 12:08. (lien). É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 Mounir (page perso, ) le 30/01/2006 à 13:54. (lien). É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).
  
  --
  Ce n'est pas sur linux...
  - [^]Re: utilité ?
    
    Posté par sylvain cherrier (page perso, ) le 30/01/2006 à 14:32. (lien). É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 Moun's (page perso, ) le 30/01/2006 à 16:39. (lien). É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 Xavier Maillard (Jabber id, page perso, ) le 30/01/2006 à 18:32. (lien). É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 ? :)
        
        --
        Xavier Maillard
        Rapport Cedras
        NON A NICOLAS SARKOZY
        NON A NICOLAS SARKOZY
      - [^]Re: utilité ?
        
        Posté par Yannick (page perso, ) le 30/01/2006 à 22:16. (lien). É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 dark_moule () le 30/01/2006 à 23:08. (lien). É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 lasher () le 01/02/2006 à 10:04. (lien). É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 lasher () le 01/02/2006 à 09:57. (lien). É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 Moun's (page perso, ) le 01/02/2006 à 17:48. (lien). É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 golum () le 31/01/2006 à 10:49. (lien). É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 Mounir (page perso, ) le 31/01/2006 à 16:51. (lien). É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 ?
      
      --
      Ce n'est pas sur linux...
      - [^]Re: utilité ?
        
        Posté par golum () le 01/02/2006 à 09:55. (lien). É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 lasher () le 01/02/2006 à 10:06. (lien). É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 yapacpuca () le 30/01/2006 à 20:37. (lien). Évalué à 2.
  Juste pour être certain Zope ne raisonne pas lui aussi en persistance d'objet avec la ZopeDB?.
  - [^]Re: utilité ?
    
    Posté par __caffeine__ () le 31/01/2006 à 19:43. (lien). É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 Arthur Accroc () le 30/01/2006 à 18:19. (lien). É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 .

--
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.

[+] Jamais entendu parler, mais c'est une bonne nouvelle quand même!

Posté par Sixel (page perso, ) le 30/01/2006 à 11:41. (lien). É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 Frédéric Desmoulins (page perso, ) le 30/01/2006 à 12:10. (lien). É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 john Smith (page perso, ) le 30/01/2006 à 12:19. (lien). É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 erik_lallemand (page perso, ) le 30/01/2006 à 13:06. (lien). É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 Frédéric Desmoulins (page perso, ) le 30/01/2006 à 13:23. (lien). Évalué à 2.
    A ma connaissance, Postgres est un SGBDR, pas un SGBDO.
    - [^]Re: Excellente nouvelle
      
      Posté par erik_lallemand (page perso, ) le 30/01/2006 à 16:42. (lien). É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 Jerome Alet (page perso, ) le 30/01/2006 à 18:50. (lien). É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 Arthur Accroc () le 30/01/2006 à 19:22. (lien). É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...) ?
        
        --
        Berlin 1936, Moscou 1980, Pékin 2008.
        Jeux Olympiques, sponsor officiel de la dictature.
        Mexico 1968, Pékin 2008.
        Jeux Olympiques, sponsor officiel de la répression.
        
        [^]Re: Définition
        
        Posté par Jerome Alet (page perso, ) le 30/01/2006 à 19:32. (lien). É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 erik_lallemand (page perso, ) le 30/01/2006 à 21:50. (lien). É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 Arthur Accroc () le 30/01/2006 à 18:52. (lien). É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)...
        
        --
        Berlin 1936, Moscou 1980, Pékin 2008.
        Jeux Olympiques, sponsor officiel de la dictature.
        Mexico 1968, Pékin 2008.
        Jeux Olympiques, sponsor officiel de la répression.
      - [^]Re: Excellente nouvelle
        
        Posté par djano () le 09/02/2006 à 13:06. (lien). É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 jepostesurlatribune () le 30/01/2006 à 13:17. (lien). É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 B r u n o (page perso, ) le 30/01/2006 à 13:52. (lien). É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 lorill (page perso, ) le 30/01/2006 à 14:38. (lien). É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 Arthur Accroc () le 30/01/2006 à 18:27. (lien). É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.
  
  --
  Berlin 1936, Moscou 1980, Pékin 2008.
  Jeux Olympiques, sponsor officiel de la dictature.
  Mexico 1968, Pékin 2008.
  Jeux Olympiques, sponsor officiel de la répression.

ZODB ?

Posté par Jerome Alet (page perso, ) le 30/01/2006 à 13:23. (lien). É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 golum () le 01/02/2006 à 14:40. (lien). É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 Julien (page perso, ) le 31/01/2006 à 10:03. (lien). É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 golum () le 31/01/2006 à 10:51. (lien). Évalué à 1.
trop poilu !
passera pas

[^]Re: performance

Posté par Jerome Alet (page perso, ) le 31/01/2006 à 11:48. (lien). Évalué à 0.
Aucun rapport entre les deux, c'est comme si tu comparais une voiture avec un sandwich.
- [^]Re: performance
  
  Posté par Jerome Alet (page perso, ) le 31/01/2006 à 11:50. (lien). É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 Julien (page perso, ) le 31/01/2006 à 13:53. (lien). É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 Cyrille Pontvieux (Jabber id, page perso, ) le 08/02/2006 à 10:44. (lien). É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 ioguix (Jabber id, ) le 31/01/2006 à 19:28. (lien). É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 :)

--
ioguix

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Première publication en licence libre du SGBDO EyeDB

utilité ?

[^]Re: utilité ?

[+] [^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[+] Jamais entendu parler, mais c'est une bonne nouvelle quand même!

Excellente nouvelle

[^]Re: Excellente nouvelle

[+] [^]Re: Excellente nouvelle

[^]Re: Excellente nouvelle

[^]Re: Excellente nouvelle

[^]Re: Excellente nouvelle

[^]Définition

[^]Re: Définition

[^]Re: Définition

[^]SGBDO vs SGBDRO

[^]Re: Excellente nouvelle

[^]Re: Excellente nouvelle

[^]Re: Excellente nouvelle

[^]Re: Excellente nouvelle

[^]Autres SGBDO

ZODB ?

[^]Re: ZODB ?

performance

[^]Re: performance

[^]Re: performance

[^]Re: performance

[^]Re: performance

[^]Re: performance

Vivement d'autre language de liaison