Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
la BDD s'en fout, c'est à l'IHM de s'en occuper. La différence avec les SGBDOO c'est que modifier un table a un impact bien moins gênant qu'un objet.
PS : Pour conserver l'intérêt et le sérieux de ce débat merci d'éviter les sarcasmes et autres ironies douteuses
Alors plusieurs points :Envoyé par orafrance
- On ne parlait pas spécifiquement de SGBDOO. On dérivait gentiment vers une confrontation OO (couche applicative Java ou autre) vs T-SQL / PL/SQL dans une BDD.
- Je suis navré, mais ajouter une propriété à un objet a autant d'impact que d'ajouter une colonne à une table.
Même si le point 1. est une petite dérive, il n'est pas si éloigné que ça du sujet de base. L'avenir des bases de données passe aussi par leur positionnement au sein d'une architecture d'entreprise : centre de décision ou simple entreprôt d'objets pour un serveur d'application ?
Je me suis permis un brin de sarcasme (et je m'en excuse), car tu sembles minimiser la complexité que peuvent atteindre des traitement métiers.
On pourrait rester sur ton exemple d'anniversaire et y ajouter quelques problématiques. Par exemple qu'il soit envoyé à chaque client un cadeau personnalisé (y en a qui aiment le vin, d'autre le chocolat et d'autre les montres, et d'autres...). La commande du cadeau se fait automatiquement par la consommation d'un webservice chez le fournisseur, webservices qui ne partagent pas les mêmes comportements et interfaces bien entendu. Pour pimenter, ajoutons encore que les prestataires externes ont aussi droit à des cadeaux, que le budget alloué au cadeau doit être validé/plafonné selon certains critères : pour les clients on regarde soit le CA, soit la rapidité de paiement selon le groupe de produit, et pour les prestataires, on regarde l'ancienneté et les rabais accordés.
Je n'ai aucun doute sur la faisabilité de ce petit scénario dans Oracle par exemple, mais je pense qu'un modèle objet sera plus souple et plus facile à maintenir et à faire évoluer dans ce cas car certains mécanismes disponible en Java ou C# permettront de réduire drastiquement le nombre de lignes de code nécessaires.
euh non mais là je crois qu'il y a un truc qui n'est pas clair... un aucun cas le SGBD ne doit gérer les problématiques métiers... là tu me parles de programmation et pas de BDD. Alors oui, effectivement le PL/SQL n'est probablement pas le meilleur langage pour développer une interface web, ça ça fait aucun doute. Mais que le stockage d'une donnée soit conditionnée par le langage de programmation ça c'est pas normal. Stocker des tables d'objets plutôt que d'utiliser un bon vieux modèle Merise normé, selon moi c'est pas une bonne manière de faire... en tout cas, Oracle n'est clairement pas fait pour ça SELON MOI, malgrès les efforts déployer pour faciliter la programmation objet au sein de la base.
Un objet applicatif doit rester une table ou à défaut une vue et le PL/SQL doit rester un moyen technique pour pallier aux carences de langage de programmation (j'ai vu hibernate à l'oeuvre par exemple... bah c'est pas joli joli)
Alors la programmation objet oui mais un SGBDOO non... c'est mon avis
Non, ce n'étaient pas des équipes de rigolos, mais des équipes avec des références sérieuses et quallifiées. J'ai en plus quelque fois fait faire des audit par des experts de chez "expert +" de leur travail.
Pour les couts de maintenance, c'est simple : je regarde le fonctionnel, je me dis "ça vaut combien en L4G Thick Database ?", je multiplie le chiffre par 5 ou 10 et j'ai la valeur. La valeur des dev objet m'est ensuite donnée par 2 équipes différentes et c'est toujours dans la fourchette.
<Mode faut pas le prendre mal = ON>
C'est marrant ce que tu dis sur les "cascades d'objets" je ne sais plus quel gourou écrivait qu'il fallait éviter les cascades d'objets sinon on s'y perd. L'avantage quand on regarde la littérature sur l'objet c'est qu'on y trouve tout et son contraire. Bon, et si les objet c'est là pour remplacer des cascades de IF, c'est un peu lourd et contraignant pour pas grand chose.
Pourtant si, OO = plus de code. Cf le liens que j'ai mis plus haut. C'est vrai que les ateliers java ou .NET proposent des tas d'outils qui resolvent des tas de problème qu'on aurait pas si on ne faisait pas de l'objet.
<Mode faut pas le prendre mal = OFF>
L'objet n'est pas un outil inventé pour calmer les complexes des informaticiens de gestion, l'objet est un outil qui a été inventé par des gens qui font des outils, des os, des gestionnaires d'interface graphique et autres systemes temps réels, ils avaient probablement besoin de ça, je ne suis pas compétent pour juger de leur travail, mais d'après mon experience pour les informaticiens de gestion, c'est plutôt une cata.
Je me permet de remettre ce lien qui correspond bien à ce que j'ai constaté, sur des petits et sur des gros projets : http://www.dulcian.com/Articles/Thic...ited_final.htm
Inutile. Comme je te l'ai dit, je ne suis pas dogmatique...donc aucune chance que je prenne mal des critiques concernant le développement objets.<Mode faut pas le prendre mal = ON>
Je ne parle pas de cascades d'objets, je parle d'une hiérarchie.
Et il est communément accepté qu'il faut idéalement conserver une hiérarchie d'objets large mais peu profonde.
Dieu merci non, l'OO n'est pas là que pour ça. Mais sur le point précis de l'enfer des IF, il est considérablement plus souple de traiter des nouveaux cas de figure par simple ajout d'une classe dans une hiérarchie que de remonter une cascade d'appels procéduraux pour ajouter un enième IF à l'endroit qui va bien.
Les outils de tests unitaires et de couverture de code ne sont pas des outils qui résolvent des problèmes OO que l'on aurait pas si l'on ne faisait pas d'OO...
Par ailleurs, je ne conteste pas l'article sur lequel tu t'appuies; je peux très facilement imaginer des tas de scénarii dans lesquels cette approche est meilleures sur bien des points par rapport à une approche OO classique.
Néanmoins, j'emets quelques réserves, particulièrement sur la première "success story" citée, et en l'absence de (code) source(s), je me permets d'être très très dubitatif, d'autant plus que Dulcian est un intégrateur Oracle.
Dulcian est un intégrateur Oracle en effet, mais ce qui est dit est valable pour Sqlserver.
Pour le développement, Oracle ne prône pas particulièrement les approches Thick DB et pousse même son atelier Jdeveloper.
"Les outils Java qui proposent des outils qui resolvent des problèmes qu'on n'aurai pas si on ne faisait pas de l'objet" c'est une boutade. De même que les cascades de IF.
Je ne m'appuie pas que sur un article, j'illustre avec un article ce que j'ai constaté par experience.
Je pense que ce que j'ai constaté est une experience partagée par tout ceux qui connaissent ou ont observé véritablement les deux mondes.
Je ne mets pas en doute ta (longue ?) expérience, mais je pense si tu as pu arriver à de telles conclusions c'est que tu as été confronté a des types de projets particuliers; des types de projets qui profitent de cette approche.
Comme je te l'ai dit, je ne suis pas dogmatique. Au cours de ma carrière j'ai moi-même été confronté à des cas dans lesquels je me disais que la pertinence de construire un modèle objet était vraiment très limitée étant donnée que l'application se contentait de chercher et afficher des données, en appliquant parfois quelques traitements tellement simples qu'il n'était même pas utile de sortir du scope du langage SQL de base.
Maintenant, il existe aussi de nombreux projets comportant des fonctionnalités qui excluent cette approche "Thick Database". Le premier exemple qui me revient à l'esprit est un moteur décisionnel qui s'appui sur un interpréteur de règles; les-dites règles étant crées par des utilisateurs non-informaticiens par le biais d'un outil graphique. J'ai beau cherché très loin, je ne vois pas comment on aurait pu produire un tel système plus rapidement en PL/SQL qu'en C#...
Par ailleurs, j'aimerais quand même revenir sur certains arguments de ton article :
Il y a quand même un sous-entendu qui me déplaît fortement : celui qui dit qu'un bon développeur Java est forcément une grosse quiche en SQL. Je pense quand même qu'il y a plus de facteurs et de possibilités d'amélioration des perfs au niveau du design et du tuning d'une base que dans la façon d'écrire des requêtes en admettant que l'on évite les erreurs grossières.
Là on enfonce une porte ouverte...
Je n'ai pas pu m'empêcher de rire à la lecture de cette partie.
Ces arguments ne sont absolument pas propres à cette approche et il peuvent simplement être transposés dans un argumentaire sur les bénéfices d'une architecture logicielle en couches...
Dans la même lignée que l'argument précédent...Avec une idée sous-jacente supplémentaire, celle que du code PL/SQL serait plus simple à maintenir et à faire évoluer que du code OO
J'en connais beaucoup qui riraient aux éclats en lisant cela, mais comme il s'agit de grosses quiches du SQL, ça ne compte pas.
Pour conclure, OUI ! Cette approche "Thick Database" est une excellente façon de faire les choses dans de nombreux cas et elle devrait encore gagner en popularité au fur et à mesure que des architectes opteront pour des SOA.
Mais NON ! Cette approche n'est pas la réponse universelle. Des cas de figure complexes lui font rapidement toucher ses limites et je ne crois pas aux arguments "moins de code" et "plus facile à maintenir"...
En effet, en plus de 20 ans de travail dans les bases de données, j’en ai vu défiler des modes.
Pour dévelloper un moteur de règle, en effet, on peut coder du C#. On peut aussi utiliser ca : http://download.oracle.com/docs/cd/B...ule.htm#996730
Il y a des chances qu’à la fin, cela sera plus simple, plus performant et plus maintenable.
J'ai eu une équipe qui faisait du calcul en C# plutot que dans la base... Avec tout les bons arguments (c'est du calcul, pas de la gestion de données donc pas dans la base, c'est du métier, donc pas dans la base,...). Donc, entre 5 et 7 développeurs C# pendant 2 ans. A la fin, poubelle : trop lent, incapable de traiter du volume,... J'ai recruté un développeur PL, on a tout refait en 6 mois. Ca marche tout seul. Nous avons utilisé une petite fonctionnalité objet de PL sur un point bien précis, je dois le dire pour etre honnete, mais nous aurions pu nous en passer. Ce n'est pas ça qui nous a fait gagner du temps et de la performance.
Il est écrit qu’un programmer PL ira plus vote qu’un programmer java. Je pense qu’on fait là plus une distinction entre l’outil utilisé et le niveau d’experience. Il n’y a pas plus de sous entendu sur la compétence java de programmer PL que sur la compétence PL du programmer Java.
Je ne suis pas là pour défendre l’auteur, mais je ne pense pas qu’il dénigre l’approche de logiciel en couche : il est en train de la promouvoir en disant « laissez le sgbd faire le stockage et le « métier », faite la presentation avec autre chose ». Si cela te fait rire, c’est bien !
Pour quelqu’un de pas dogmatique, tu as un curieux ton (quiche, l’avis ne compte pas, rire aux éclats …).Dans la même lignée que l'argument précédent...Avec une idée sous-jacente supplémentaire, celle que du code PL/SQL serait plus simple à maintenir et à faire évoluer que du code OO
J'en connais beaucoup qui riraient aux éclats en lisant cela, mais comme il s'agit de grosses quiches du SQL, ça ne compte pas.
La différence entre les tenants de l’objet dans l’informatique de gestion principalement et ceux qui interroge cette approche est d’un point de vue « dialectique » assez simple. D’un coté il y a des gens qui disent « l’objet c’est mieux, c’est plus maintenable, c’est plus… » que quoi, on ne sait pas, mais comme tout le mode ou prsque le dit, c'est mieux. En général, en effet, ils ne connaissent en effet que le monde objet ou n'ont pas de point de comparaison. "En général", c'est pas terrible, disons que je n'en ai pas trouvé. D’autre part, il y a des gens qui vivent avec les deux mondes et comparent des expériences, et là, je commence à en trouver !
Je ne parle que de ce que je connais, l’informatique de gestion
Ce n’est pas un argument, c’est un retour d’experience.
Et c'est sa qui est fatiguant dans ce débat. Confondre de "l'argumentaire" et du "retour d'experience".
Je n'ai jamais vu d'analyse du retour d'experience sur l'objet à part deux ou 3.
Les seuls que j'ai vu comparer des projet et du code sont ceux qui disent "ou là, l'objet attention !".
Je pense qu'il est preferable que nous en restions là, nous n'arriverons pas à nous faire changer d'avis l'un l'autre et avons clairement chacun donné nos positions.
Oui, si on est sous Oracle.Pour dévelloper un moteur de règle, en effet, on peut coder du C#. On peut aussi utiliser ca : http://download.oracle.com/docs/cd/B...ule.htm#996730
D'accord. Donc sur ce retour d'expérience, entre 10 et 14 années de boulot en C# donnent un résultat nettement inférieur à 6 mois de PL/SQL...
Tu comprendras que devant un écart aussi astronomique, quelqu'un qui connait les deux mondes (ben oui, tu n'est pas le seul quand même), puisse remettre sérieusement en cause le niveau de l'équipe C#.
Je ne dis pas que l'auteur dénigre quoi que ce soit (merci de ne pas déformer mes propos). Je dis juste que cet argument n'est pas spécifique à l'approche "Thick Database".
Vu le résultat des 2 audits par des entreprises spécialisées, c'était "normal".
C'est effectivement surprenant comme résultat ...
Et tu expliques cela par une mauvaise utilisation de l'approche OO ou carrément que cette dernière n'était pas adaptée au problème posé quelle que soit par ailleurs l'équipe ou le langage utilisé ?
Je pense, d'après mon experience, que la POO n'est globalement pas adaptée à l'informatique de gestion.
De temps en temps, elle peut participer à la résolution des problèmes.
Utilisée systématiquement, elle augmente les coûts de dév, le volume de code etc.
Je constate que l'approche "le métier" doit être dans un server d'application objet et tout ce qui fait "du métier" doit passer par là est une approche plus handicapante (coût, performances, etc.) et rigide qu'autre chose.
Quand en plus on oppose tout ça à une approche "thick DB", on obtient des éléments de comparaison interressant. C'est pour ça que je dis "d'après mon experience" et "je constate".
L'équipe au qui le travail était confié était "C# ement" compétente. Ils n'ont pas appris à programmer avec pour ce projet. On peut toujours imaginer une équipe "C# ement" plus compétente mais une équipe de développement ne doit pas être une équipe d'experts et de consultants, cela doit être une équipe de développement.
Je n'ai pas constaté ça qu'avec du C#, mais aussi avec du Java et du C++.
bah voila qui vérifie le sous-entendu
L'optimisation d'un traitement qui implique un SGBD suit l'ordre suivant :
- revue du modèle de données
- revue du choix du langage
- revue de la requête
Et seulement après : tuning base et enfin tuning OS et hardware.
dans 98% des cas, un problème de performance n'a rien à voir avec le tuning, quel qu'il soit. Tout au plus le tuning peut-il pallier les carences du reste et encore, c'est pas toujours faisable. Et à vu de nez, dans 75% des cas, la réécriture d'une requête ou un plan d'indexation bien pensé suffit à régler les problèmes de perf.
Et ça, malheureusement avec les outils de mapping on passe au travers puisque la requête est générée... ETL et mapping sont les 2 maux d'un DBA
J'ai fait du SQL avant de faire de l'OObah voila qui vérifie le sous-entendu
Cela me paraît censé, mais il faut juste s'entendre sur ce qu'on inclut dans le terme "tuning"...
Lorsque j'ai écrit ça, j'avais en tête l'indexation comme faisant partie du tuning, mais à la lumière de ta réponse, je suppose que tu classes plutôt ça dans le modèle de donnés.
Toujours est-il qu'au delà des termes, je pense que nous sommes d'accord.
Je ne m'avancerai pas sur un pourcentage, mais il me semble quand même que la majorité des problèmes de performance sont réglés par une revue du modèle (indexation comprise) et qu'à l'exception des mauvaises pratiques que l'on peut corriger, les possibilités pour améliorer un traitement sous-performant au niveau de la requête seulement sont plus limitées.
Je ne suis pas un grand fan des outils de mapping pour (entre autre) cette raison, mais je dois reconnaître que j'ai pu constater que la cause de requêtes générées moisies était souvent un modèle lui-même très "approximatif".Et ça, malheureusement avec les outils de mapping on passe au travers puisque la requête est générée... ETL et mapping sont les 2 maux d'un DBA
Par ailleurs, tous les ORM un tant soit peu aboutis laissent toujours la possibilité de créer "manuellement" les requêtes pour les cas ou la génération automatique n'arrive pas à produire quelque chose d'optimisé.
c'est la différence entre un bon et un mauvais pratiquant du SQLJ'ai fait du SQL avant de faire de l'OO
changement des paramètres de démarrage de l'instance, gestion du stockage, statistiques, etc... ce qui impacte l'ensemble de la base en fait
En effet
C'est vrai mais il est souvent plus simple de revoir une requête que le modèle de données quand l'appli est en exploitation
La question reste donc entière... qu'elle intérêt d'utiliser un ORM si c'est pour finalement lui faire toutes les requêtes ? Et on en revient là où je voulais en venir : les vues et procédures stockées sont là pour extraire les données, le java et ses objets ne devant servir qu'à l'IHM
L'intérêt est que les requêtes trop complexes pour être générées correctement par un ORM ne sont pas forcément majoritaires.
Un ORM va te faire gagner pas mal de temps sur toutes les relations "simples", du genre un objet = une table et aussi certains trucs un poil plus complexe comme un objet "enfant" = une table "enfant".
???
Ben si c'est pour gagner du temps là dessus, c'est pour gagner du temps sur 0,1% du projet !
Avec les techniques des L4G (forms, power builder, uniface...) c'est (c'était) "gratuit" ce genre de choses !
De plus en plus, j'assiste à des problemes de perf qui sont du, non pas à des problèmes de requête ou d'indexation, mais à des problèmes de localisation de traitement (sgbd versus server d'application).
Je ne suis pas très loin de penser cela, mais dans un contexte totalement différent ...
Je suis actuellement dans un environnement Mainframe ( IBM z/OS et DB2 ) et chez nous s'opposent :
- une architecture actuelle "classique" à deux couches :
1) IHM (typiquement un navigateur) sur le poste de travail2) moniteur transactionnel IMS/TM sur le mainframe avec des programmes écrits en COBOL et des accés SQL intégrésLe lien étant fait par un "middleware" maison de type CORBA
- une architecture future à trois couches :
1) IHM (typiquement un navigateur) sur le poste de travail2) serveur de type Websphere avec des programmes écrits en JAVA qui détiennent les règles "métier"3) procédures stockées sur le DB2 z/OS pour l'accès aux données
La faisabilité et les performances de l'architecture à trois couches me semblent vraiment problématiques ...
Répondre avec citation
Partager