Comparatif de qqs SGBDRs, et les SGBDROO : vos avis ?
5 réponses
Alomphega
Bonjour,
Sur les conclusions des tests :
http://polepos.sourceforge.net/results/html/index.html
Il est dit :
"If you take a look at the sources of the tests, they are also a
measurement, how easy it is to work against a specific database. SQL
looks like a foreigner in Java code, very ugly, difficult to write and
refactor. O-R mappers and object databases make life so much easier and
productive. The task of storing objects is very similar among all the
products tested. If a strong mainstream standard for object oriented
querying can be reached, SQL will lose ground. This will happen for
sure, the question is, how long it will take."
En résumé, il est dit que le langage SQL s'effacera inévitablement
devant la conception SGBDR orientée objet.
Je crois aussi que cette assertion est exacte.
Ma question : existe-t-il des SGBDR "Objets" à l'heure actuelle en
OpenSource et utilisables ?
Cordialement,
--
Guy AJ Capra
________________________
http://www.alomphega.com
http://www.openmeans.org
En résumé, il est dit que le langage SQL s'effacera inévitablement devant la conception SGBDR orientée objet.
Je crois aussi que cette assertion est exacte.
meuh non, tout le monde sait bien que l'avenir c'est pickorette :-D
François Girault
Alomphega a écrit :
Bonjour,
Sur les conclusions des tests : http://polepos.sourceforge.net/results/html/index.html
Il est dit : "If you take a look at the sources of the tests, they are also a measurement, how easy it is to work against a specific database. SQL looks like a foreigner in Java code, very ugly, difficult to write and refactor. O-R mappers and object databases make life so much easier and productive. The task of storing objects is very similar among all the products tested. If a strong mainstream standard for object oriented querying can be reached, SQL will lose ground. This will happen for sure, the question is, how long it will take."
En résumé, il est dit que le langage SQL s'effacera inévitablement devant la conception SGBDR orientée objet.
Je crois aussi que cette assertion est exacte.
Votre résumé est un peu rapide. Il est question de "*O-R mappers* and object databases", pas que de bases de données objets. Les mappings objet-relationnel sont une technologie très productive pour des assidus de la programmation orientée objet surtout dans le cadre d'un serveur d'application.
L'accès aux données est une problématique récurente en programmation objet, et s'épargner l'écriture des requêtes et l'affectation des attributs des objets permet de gagner du temps.
Les SGBDR font depuis longtemps et avec un grand savoir-faire (voir avec talent pour certains ;) ) le boulot qu'on leur demande : stocker des données de manière intègre et les accéder efficacement. Les attributs d'un objet ne sont que des données typés, peu importe d'où qu'elles viennent.
Il y néanmoins un bémol à la chose : l'impédance entre le modèle relationnel et le modèle objet, c'est à dire comment faire cohabiter sereinement une logique objet, riche de polymorphisme, de composition ... avec un monde relationnel plus ou moins étroit (selon les gouts) mais en tout cas différents.
Utiliser un mapping objet-relationnel crée une dépendance technique forte dans un projet, car beaucoup de produits sont sous-optimisés ou pas assez riche dans les critères de sélection, etc ... D'expérience, je me suis toujours retrouvé plus ou moins bloqué à utiliser de tels produits, mais au moins 80% du boulot d'écriture de requête SQL m'était épargné. Une rustine SQL dans un coin, et hop je m'en sortais :)
Ma question : existe-t-il des SGBDR "Objets" à l'heure actuelle en OpenSource et utilisables ?
Je n'en ai pas encore utilisé, mais des ORM trainent dans tous les langages ou presque (avec souvent pour avantage de supporter plusieurs SGBDR, ce qui est sympa quand les environnement clients hétérogènes).
Pour en citer quelques uns : hibernate (java), EJB (java, mais beaucoup plus qu'un ORM), sqlobject (python), etc ... (Google est notre ami et c'est hors sujet).
Pour conclure là dessus, les ORM peuvent rendre de grands services et ont une place de choix dans les architectures à couches, mais sont parfois uzinagazesques, ou singent les comportements de SQL sur les requêtes.
Ah tiens, au fait, il n'y a aucun ORM qui supporte pick ? Ah oui, c'est vrai "pick remplace apache mozila firefox ", nul doute qu'il ne soit à la fois le meilleur ORM et la meilleure base de données objets. En plus c'est open-source. utilisable ... bah ...
-- FG
Alomphega a écrit :
Bonjour,
Sur les conclusions des tests :
http://polepos.sourceforge.net/results/html/index.html
Il est dit :
"If you take a look at the sources of the tests, they are also a
measurement, how easy it is to work against a specific database. SQL
looks like a foreigner in Java code, very ugly, difficult to write and
refactor. O-R mappers and object databases make life so much easier and
productive. The task of storing objects is very similar among all the
products tested. If a strong mainstream standard for object oriented
querying can be reached, SQL will lose ground. This will happen for
sure, the question is, how long it will take."
En résumé, il est dit que le langage SQL s'effacera inévitablement
devant la conception SGBDR orientée objet.
Je crois aussi que cette assertion est exacte.
Votre résumé est un peu rapide. Il est question de "*O-R mappers* and
object databases", pas que de bases de données objets. Les mappings
objet-relationnel sont une technologie très productive pour des assidus
de la programmation orientée objet surtout dans le cadre d'un serveur
d'application.
L'accès aux données est une problématique récurente en programmation
objet, et s'épargner l'écriture des requêtes et l'affectation des
attributs des objets permet de gagner du temps.
Les SGBDR font depuis longtemps et avec un grand savoir-faire (voir avec
talent pour certains ;) ) le boulot qu'on leur demande : stocker des
données de manière intègre et les accéder efficacement. Les attributs
d'un objet ne sont que des données typés, peu importe d'où qu'elles
viennent.
Il y néanmoins un bémol à la chose : l'impédance entre le modèle
relationnel et le modèle objet, c'est à dire comment faire cohabiter
sereinement une logique objet, riche de polymorphisme, de composition
... avec un monde relationnel plus ou moins étroit (selon les gouts)
mais en tout cas différents.
Utiliser un mapping objet-relationnel crée une dépendance technique
forte dans un projet, car beaucoup de produits sont sous-optimisés ou
pas assez riche dans les critères de sélection, etc ... D'expérience, je
me suis toujours retrouvé plus ou moins bloqué à utiliser de tels
produits, mais au moins 80% du boulot d'écriture de requête SQL m'était
épargné. Une rustine SQL dans un coin, et hop je m'en sortais :)
Ma question : existe-t-il des SGBDR "Objets" à l'heure actuelle en
OpenSource et utilisables ?
Je n'en ai pas encore utilisé, mais des ORM trainent dans tous les
langages ou presque (avec souvent pour avantage de supporter plusieurs
SGBDR, ce qui est sympa quand les environnement clients hétérogènes).
Pour en citer quelques uns : hibernate (java), EJB (java, mais beaucoup
plus qu'un ORM), sqlobject (python), etc ... (Google est notre ami et
c'est hors sujet).
Pour conclure là dessus, les ORM peuvent rendre de grands services et
ont une place de choix dans les architectures à couches, mais sont
parfois uzinagazesques, ou singent les comportements de SQL sur les
requêtes.
Ah tiens, au fait, il n'y a aucun ORM qui supporte pick ? Ah oui, c'est
vrai "pick remplace apache mozila firefox ", nul doute qu'il ne soit à
la fois le meilleur ORM et la meilleure base de données objets. En plus
c'est open-source. utilisable ... bah ...
Sur les conclusions des tests : http://polepos.sourceforge.net/results/html/index.html
Il est dit : "If you take a look at the sources of the tests, they are also a measurement, how easy it is to work against a specific database. SQL looks like a foreigner in Java code, very ugly, difficult to write and refactor. O-R mappers and object databases make life so much easier and productive. The task of storing objects is very similar among all the products tested. If a strong mainstream standard for object oriented querying can be reached, SQL will lose ground. This will happen for sure, the question is, how long it will take."
En résumé, il est dit que le langage SQL s'effacera inévitablement devant la conception SGBDR orientée objet.
Je crois aussi que cette assertion est exacte.
Votre résumé est un peu rapide. Il est question de "*O-R mappers* and object databases", pas que de bases de données objets. Les mappings objet-relationnel sont une technologie très productive pour des assidus de la programmation orientée objet surtout dans le cadre d'un serveur d'application.
L'accès aux données est une problématique récurente en programmation objet, et s'épargner l'écriture des requêtes et l'affectation des attributs des objets permet de gagner du temps.
Les SGBDR font depuis longtemps et avec un grand savoir-faire (voir avec talent pour certains ;) ) le boulot qu'on leur demande : stocker des données de manière intègre et les accéder efficacement. Les attributs d'un objet ne sont que des données typés, peu importe d'où qu'elles viennent.
Il y néanmoins un bémol à la chose : l'impédance entre le modèle relationnel et le modèle objet, c'est à dire comment faire cohabiter sereinement une logique objet, riche de polymorphisme, de composition ... avec un monde relationnel plus ou moins étroit (selon les gouts) mais en tout cas différents.
Utiliser un mapping objet-relationnel crée une dépendance technique forte dans un projet, car beaucoup de produits sont sous-optimisés ou pas assez riche dans les critères de sélection, etc ... D'expérience, je me suis toujours retrouvé plus ou moins bloqué à utiliser de tels produits, mais au moins 80% du boulot d'écriture de requête SQL m'était épargné. Une rustine SQL dans un coin, et hop je m'en sortais :)
Ma question : existe-t-il des SGBDR "Objets" à l'heure actuelle en OpenSource et utilisables ?
Je n'en ai pas encore utilisé, mais des ORM trainent dans tous les langages ou presque (avec souvent pour avantage de supporter plusieurs SGBDR, ce qui est sympa quand les environnement clients hétérogènes).
Pour en citer quelques uns : hibernate (java), EJB (java, mais beaucoup plus qu'un ORM), sqlobject (python), etc ... (Google est notre ami et c'est hors sujet).
Pour conclure là dessus, les ORM peuvent rendre de grands services et ont une place de choix dans les architectures à couches, mais sont parfois uzinagazesques, ou singent les comportements de SQL sur les requêtes.
Ah tiens, au fait, il n'y a aucun ORM qui supporte pick ? Ah oui, c'est vrai "pick remplace apache mozila firefox ", nul doute qu'il ne soit à la fois le meilleur ORM et la meilleure base de données objets. En plus c'est open-source. utilisable ... bah ...
-- FG
helios
"JustMe" a écrit dans le message de news:
Alomphega vient de nous annoncer :
> En résumé, il est dit que le langage SQL s'effacera inévitablement
devant la
> conception SGBDR orientée objet. > > Je crois aussi que cette assertion est exacte.
meuh non, tout le monde sait bien que l'avenir c'est pickorette :-D
tu crois pas si bien dire car Pick permet la COO et j'en fait dessus depuis 1986
"JustMe" <pasdespam@merci.beaucoup> a écrit dans le message de
news:mn.bbcd7d5beba22c47.15643@merci.beaucoup...
Alomphega vient de nous annoncer :
> En résumé, il est dit que le langage SQL s'effacera inévitablement
devant la
> conception SGBDR orientée objet.
>
> Je crois aussi que cette assertion est exacte.
meuh non, tout le monde sait bien que l'avenir c'est pickorette :-D
tu crois pas si bien dire car Pick permet la COO et j'en fait dessus depuis
1986
