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.
Aller plus loin
- Téléchargement (52 clics)
# utilité ?
Posté par dark_moule . Évalué à 7.
Je pense que je ne suis pas le seul à savoir et cela pourrait être certainement utile.
[^] # Re: utilité ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 . Évalué à -1.
[^] # Re: utilité ?
Posté par sylvain cherrier (site web personnel) . Évalué à 8.
- 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 Anonyme . Évalué à 4.
[^] # Re: utilité ?
Posté par sylvain cherrier (site web personnel) . Évalué à 10.
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 Mouns (site web personnel) . Évalué à 7.
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 . Évalué à 4.
[^] # Re: utilité ?
Posté par par . Évalué à 5.
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 . Évalué à 1.
[^] # Re: utilité ?
Posté par lasher . Évalué à 2.
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 . É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 Mouns (site web personnel) . Évalué à 3.
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 . Évalué à 3.
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 Anonyme . Évalué à 1.
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 golum . Évalué à 3.
[^] # Re: utilité ?
Posté par lasher . Évalué à 1.
OQL (Object Query Language) permet de faire tout ce que propose SQL, et plus.
[^] # Re: utilité ?
Posté par yapacpuca . Évalué à 2.
[^] # Re: utilité ?
Posté par __caffeine__ . Évalué à 1.
[^] # Re: utilité ?
Posté par Arthur Accroc . Évalué à 4.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Jamais entendu parler, mais c'est une bonne nouvelle quand même!
Posté par Sixel . Évalué à -10.
"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 (site web personnel) . Évalué à 5.
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 (site web personnel) . Évalué à 7.
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 . Évalué à -1.
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 (site web personnel) . Évalué à 2.
[^] # Re: Excellente nouvelle
Posté par erik_lallemand . Évalué à 2.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 3.
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...) ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Définition
Posté par Jerome Alet (site web personnel) . Évalué à 4.
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 . Évalué à 1.
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 . Évalué à 4.
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)...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Excellente nouvelle
Posté par djano . Évalué à 1.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 3.
Je connaissais db4o [http://db4o.com] qui a une double licence GPL/proprio sur le modèle MySQL.
[^] # Re: Excellente nouvelle
Posté par lorill (site web personnel) . Évalué à 4.
http://www.ozone-db.org/
[^] # Autres SGBDO
Posté par Arthur Accroc . Évalué à 4.
- 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.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# ZODB ?
Posté par Jerome Alet (site web personnel) . Évalué à 2.
[^] # Re: ZODB ?
Posté par golum . Évalué à 2.
il existe une alternative pour python: Durus
http://www.python.org/pycon/2005/papers/17/Durus.html
http://www.mems-exchange.org/software/durus/
# performance
Posté par Julien . Évalué à 0.
[^] # Re: performance
Posté par golum . Évalué à 1.
passera pas
[^] # Re: performance
Posté par Jerome Alet (site web personnel) . Évalué à 0.
[^] # Re: performance
Posté par Jerome Alet (site web personnel) . Évalué à 1.
[^] # Re: performance
Posté par Julien . Évalué à 1.
[^] # Re: performance
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
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 . Évalué à 0.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.