- Ça ne résoud pas toujours tous les problèmes quand même.
Exemples ?
- Ce n'est pas toujours aussi performant que le relationnel (surtout d'un point de vue ensembliste)
Je dirais simplement : SQL est un sous-ensemble de OQL. Je rajoute aussi que SQL est non procédural, il n'a pas été conçu comme un langage applicatif. Tu es toujours dans le paradigme relationnel/procédural. Si tes objets sont bien conçus tu résouds toutes tes problématiques. Avec SQL et le modele entité relation, ta logique applicative est éclatée sur parfois 3 niveaux (serveur d'appli (java, C#, C++, Smaltalk), SGBDR (SQL), SGBDR (Proc stock PL/SQL) ). Ce qui multiplie par autant la complexité et le nombre d'experts qu'il faut pour un seul projet :-/ . OQL te permet d'appeler directement les méthodes de tes objets => la logique applicative est défini une fois pour toute et à un seul endroit ! A quoi ça te sert de prendre un Rational Rose, Together, Poseidon UML ou encore JUDE, si c'est pour développer par la suite du SQL et du trigger !
- Le relationnel, ça suffit dans la majeure partie des cas.
Dans le cas que j'enonçais dans mon post, le relationnel est largué !
Je ne suis pas convaincu par tes 3 premiers arguments.
Et surtout, si j'ai bien compris, (corrigez moi si je me trompe), c'est trés dépendant d'un langage précis en général (à cause du mapping).
Déja, je ne parlais que des langages objets (smalltalk, java,c++, C# ? ) pour chacun de ces langages il existe une base de données objets. Et si tu aimes le php des projets comme HessianPHP (http://hessianphp.sourceforge.net(...)) te permettent d'attaquer des serveurs d'applications C# et Java. D'ailleurs je te signale que PHP se met lui aussi au tout objet et le clame haut et fort. (troll à part je ne considère pas php comme un langage pour faire des projets lourds) .Pour python il existe un serveur d'application entièrement objet Plone ou Zope ?. Et puis pour VB ... j'avais dit de vrais langages ptdr! Sans blague, je connais pas bien ce monde là mais un projet comme db4o te permet d'attaquer leur SGBDOO avec du .net, alors après je sais pas les versions etc ...
Après pour ce qui est de l'implantation du relationnel en entreprise, je sais très bien, il est pas là le problème, à la base on parlait des cours dispensés en base de données, d'ailleurs j'ai évoqué l'existant dans mon post. Et puis j'ai pas parlé de migration, je sais que c'est complexe moi je parle des nouveaux projets dans les nouvelles archis.
Ce que je veux dire, est que, ok, pour le développeur, c'est jouissif, en 3 lignes il fait des choses merveilleuses, mais si elles prennent 3 fois plus de temps qu'avec un SGBDR (j'éxagère sûrement, mais l'idée est là), associé à un cout enorme de migration, où est l'avantage pour le système d'information de l'entreprise ? Où est son intérêt dans cette histoire ? (sans parler qu'actuellement, cela la rend prisonnière d'une techno comme Java par ex)
Les vraies réponses à ces dernières questions permettraient certainement de comprendre pourquoi les SGBDOOs sont encore des "niches" technologiques.
Selon toi pourquoi des projets comme hibernate voient le jour, c'est pour traiter de l'existant justement et ne faire que de l'objet en utilisant un Oracle juste comme un service de persistence. Maintenant pour ce qui est "d'être prisonnier d'une techno comme java", soit pragmatique tu penses qu'un DSI va choisir 15 technos pour son SI à partir d'un moment tu dois choisir : je ne connais pas beaucoup de boites qui font tourner et du J2EE et du .NET et du php. De plus ton exemple d'emprisonnement technologique de Java est très mal choisi car avec Java je fait des applications sur toutes les plateformes et il existe des interface vers d'autres langages (JNI) sur toutes ces plateformes. Par contre si tu choisis microsoft là tu peux parler d'emprisonnement car tu es obligé et contraint de rester sur cette plateforme. À mon sens les SGBDOO ne sont plus une niche technologique.
Pour finir, je préfère que le consultant que je paie 600 euros la journée fasse ma fonctionnalité en 3 lignes plutot que : 1 - modifier le java , 2 - modifier le SQL (+index + types + contraintes), 3 - modifier les proc/stok en PL/SQL. Non seulement il coute plus chèr car il doit connaitre 3 technos et en plus à périmètre constant il va prendre plus de temps :-/ , je préfère le tout objet ...
Maintenant je ne me penche pas vers les migrations. Je m'oriente vers les nouveaux projets. Le relationnel j'en ai vraiment marre ...
[^] # Re: Base de données ... relationnelles (soyons précis)
Posté par Narmer . En réponse au journal Ma vie, mon oeuvre ;-). Évalué à 3.
Exemples ?
Je dirais simplement : SQL est un sous-ensemble de OQL. Je rajoute aussi que SQL est non procédural, il n'a pas été conçu comme un langage applicatif. Tu es toujours dans le paradigme relationnel/procédural. Si tes objets sont bien conçus tu résouds toutes tes problématiques. Avec SQL et le modele entité relation, ta logique applicative est éclatée sur parfois 3 niveaux (serveur d'appli (java, C#, C++, Smaltalk), SGBDR (SQL), SGBDR (Proc stock PL/SQL) ). Ce qui multiplie par autant la complexité et le nombre d'experts qu'il faut pour un seul projet :-/ . OQL te permet d'appeler directement les méthodes de tes objets => la logique applicative est défini une fois pour toute et à un seul endroit ! A quoi ça te sert de prendre un Rational Rose, Together, Poseidon UML ou encore JUDE, si c'est pour développer par la suite du SQL et du trigger !
Dans le cas que j'enonçais dans mon post, le relationnel est largué !
Je ne suis pas convaincu par tes 3 premiers arguments.
Déja, je ne parlais que des langages objets (smalltalk, java,c++, C# ? ) pour chacun de ces langages il existe une base de données objets. Et si tu aimes le php des projets comme HessianPHP (http://hessianphp.sourceforge.net(...)) te permettent d'attaquer des serveurs d'applications C# et Java. D'ailleurs je te signale que PHP se met lui aussi au tout objet et le clame haut et fort. (troll à part je ne considère pas php comme un langage pour faire des projets lourds) .Pour python il existe un serveur d'application entièrement objet Plone ou Zope ?. Et puis pour VB ... j'avais dit de vrais langages ptdr! Sans blague, je connais pas bien ce monde là mais un projet comme db4o te permet d'attaquer leur SGBDOO avec du .net, alors après je sais pas les versions etc ...
Après pour ce qui est de l'implantation du relationnel en entreprise, je sais très bien, il est pas là le problème, à la base on parlait des cours dispensés en base de données, d'ailleurs j'ai évoqué l'existant dans mon post. Et puis j'ai pas parlé de migration, je sais que c'est complexe moi je parle des nouveaux projets dans les nouvelles archis.
Selon toi pourquoi des projets comme hibernate voient le jour, c'est pour traiter de l'existant justement et ne faire que de l'objet en utilisant un Oracle juste comme un service de persistence. Maintenant pour ce qui est "d'être prisonnier d'une techno comme java", soit pragmatique tu penses qu'un DSI va choisir 15 technos pour son SI à partir d'un moment tu dois choisir : je ne connais pas beaucoup de boites qui font tourner et du J2EE et du .NET et du php. De plus ton exemple d'emprisonnement technologique de Java est très mal choisi car avec Java je fait des applications sur toutes les plateformes et il existe des interface vers d'autres langages (JNI) sur toutes ces plateformes. Par contre si tu choisis microsoft là tu peux parler d'emprisonnement car tu es obligé et contraint de rester sur cette plateforme. À mon sens les SGBDOO ne sont plus une niche technologique.
Pour finir, je préfère que le consultant que je paie 600 euros la journée fasse ma fonctionnalité en 3 lignes plutot que : 1 - modifier le java , 2 - modifier le SQL (+index + types + contraintes), 3 - modifier les proc/stok en PL/SQL. Non seulement il coute plus chèr car il doit connaitre 3 technos et en plus à périmètre constant il va prendre plus de temps :-/ , je préfère le tout objet ...
Maintenant je ne me penche pas vers les migrations. Je m'oriente vers les nouveaux projets. Le relationnel j'en ai vraiment marre ...