Publicité

Affichage des résultats du sondage: Rencontrez-vous des réticences d'usage des outils de mapping O/R de vos DBA

Votants
45. Vous ne pouvez pas participer à ce sondage.
  • Non, pas de réticence du tout

    23 51,11%
  • Oui, des réticences au départ mais plus maintenant

    9 20,00%
  • Oui, des réticences et même que l'on ne peut pas utiliser ces outils

    13 28,89%
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 3 123 DernièreDernière
Affichage des résultats 1 à 20 sur 54
  1. #1
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 843
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 843
    Points : 2 929
    Points
    2 929

    Par défaut Comment sont perçus les outils de mapping Objet / Relationnel (JPA, Hibernate, etc.) par vos DBA ?

    Bonjour,

    concernant les outils de mapping O/R, JPA, Hibernate et autres, rencontrez-vous des réticences de la part de votre DBA ? Des "peurs" du genre : Ouhai avec ces outils, on ne maitrise pas le SQL exécuté, il est préférable d'avoir les requêtes en dur au moins on sait ce que l'on fait

    Si bien sûr il y a des DBA (des vrais de vrais ) qui peuvent se prononcer, ça serait encore mieux

    Merci à vous

    [Edit]
    Pour information, un débat existant complémentaire qui traite du point de vue particulier de la performance : Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?

    N'hésitez pas à faire un retour d'expérience sur d'autres axes de perception / évaluation.

  2. #2
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    Non chez nous...

    Ce n'est pas vraiment le rôle d'un DBA de se prononcer sur une solution technique, il est plutôt là pour optimiser la base et la "gérer" au sens large.

    De plus, ce n'est pas hibernate ou un orm qui génère forcément une diminution des performances mais l'application qui peut être plus ou moins gloutonne en requête DB ou qui n'optimise pas ses accès.
    Ce sont plutôt les chef de projets qui expriment des craintes par rapport aux orm (surtout ceux qui ne veulent pas se remettre en cause).
    Pour ce qui est de la "non maîtrise" du code, c'est plus ou moins vrai...
    On peut tout de même agir sur la manière de générer la requête.
    J'ai fait des applications de gestion avec Hibernate et d'autres sans.
    Je ne sent pas de baisse significative des performances qu'on pourrait imputer à l'ORM

  3. #3
    Expert Confirmé Sénior


    Inscrit en
    octobre 2003
    Messages
    7 880
    Détails du profil
    Informations forums :
    Inscription : octobre 2003
    Messages : 7 880
    Points : 30 522
    Points
    30 522

    Par défaut

    Pour information, un débat existant complémentaire qui traite d'un axe particulier (performances) : Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?

  4. #4
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    Citation Envoyé par Ricky81 Voir le message
    Pour information, un débat existant complémentaire qui traite d'un axe particulier (performances) : Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?
    Je ne l'avais pas vu celui là (et quelque part, après avoir lu les 6 pages, on reste baba). Personnellement, je trouve l'avis totalement partial, visiblement sans pratique d'un orm... bref, un gars qui nous dira que programmer en assembleur c'est vachement plus performant...

    Je préfère perdre 100ms pour un traitement particulier que de perdre 3 semaines à essayer de comprendre ce qu'on avait voulu faire et à retrouver la couche impliquée... (mais non, je n'exagère pas )
    Quant à l'aspect portabilité (inter-bases), la procédure stockée n'est vraiment pas la panacée.
    Bon, pour ne pas paraitre aussi "jusqu'au boutiste" que l'auteur, je dirais pour ma part qu'il vaut mieux tirer partie des avantages des uns et des autres plutôt que de dire "ça c'est de la merde et ça c'est le saint graal".
    Rien n'empêche de faire faire 95% du boulot à l'ORM et de passer par des procédures stockées ou du sql natif pour le reste.

  5. #5
    Membre Expert

    Homme Profil pro François Durand
    Spécialiste Delivery Mainframe IBM
    Inscrit en
    octobre 2005
    Messages
    1 219
    Détails du profil
    Informations personnelles :
    Nom : Homme François Durand
    Âge : 55
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Spécialiste Delivery Mainframe IBM
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 219
    Points : 2 079
    Points
    2 079

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    ...
    Ce n'est pas vraiment le rôle d'un DBA de se prononcer sur une solution technique, il est plutôt là pour optimiser la base ...
    Optimiser une Base de données sans avoir la connaissance très précise des accès réalisés m'apparaît pour le moins difficile ... mais je pars du postulat, peut être faux après tout, que ces outils de mapping n'offrent pas une bonne visibilité sur le SQL généré ou que ce dernier est trop générique pour être raisonnablement optimisé ...

  6. #6
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    Que veux-tu dire par "visibilité du sql généré" ?
    La possibilité de voir ce code ou d'intervenir dessus ?

    Hibernate (pour en citer un) permet de faire des choses très précises en terme de requête.
    Dans la mesure où on utilise l'orm pour la création/mise à jour des enregistrements (c'est évidement le cas général), il va de soit que ça se fait sur une "entité" représentant un enregistrement complet (on peut également jouer sur les mises à jour cascade pour propager les modifications sur des fils à partir du père). C'est ce qu'on appelle généralement un CRUD. Là, il n'y a guère d'optimisation possible... En JDBC, on pourrait faire plus fin...

    Pour la partie extraction des données, on peut par contre faire à peu près ce qu'on veut, ne récupérer que quelques colonnes, etc...
    Bref, j'attends de savoir ce que tu voulais dire avant de continuer...

    Pour le boulot d'un DBA, je suis bien d'accord qu'il doit connaître la nature des accès pour les optimiser... ce qui ne veut pas dire que son avis dans le choix d'une technologie sera déterminant... Si le projet consistait à développer une application multi-client, multi-bases (cas d'un progiciel), je pense qu'on ne prendrait même pas la peine de le consulter...

    Pour le reste, un DBA pourra en analysant la charge du SGBDR définir de nouveaux index ou vue pour optimiser les temps de réponses.

  7. #7
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 843
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 843
    Points : 2 929
    Points
    2 929

    Par défaut

    mais je pars du postulat, peut être faux après tout, que ces outils de mapping n'offrent pas une bonne visibilité sur le SQL généré ou que ce dernier est trop générique pour être raisonnablement optimisé ...
    Il n'est pas générique, absolument pas.
    Le truc c'est simplement de pouvoir écrire, par exemple si on prend l'exemple d'Hibernate, un ordre simple comme (genre) :

    Code :
    Dossier d = getJdbcTemplate().load(12,Dossier.class);
    où 12 est la clé primaire du Dossier recherché.

    Dans le fichier de mapping, on a décrit par exemple que :

    Les objets Dossier sont stockés dans la table TDOSSIER
    L'attribut id est stocké dans la colonne ID
    L'attribut numero est stocké dans la colonne C-NUM
    L'attribut Libellé est stocké dans la colonne N-LIB

    Hibernate va alors fabriquer la requête :
    Code :
    1
    2
     
    SELECT d.id, d.c-num,d.n-lib FROM tdossier d WHERE d.id = 12
    C'est tout.
    Il n'y a rien, absolument rien de générique. Tout peut être anticipé en fonction du mapping.
    L'idée du langage HQL d'Hibernate, qui est très très proche de SQL, est simplement de permettre de nommer les noms Java des objets/attributs à la place de leur correspondant SQL. Cela permet avant tout l'écriture d'un code "SQL" (HQL donc) proche du fonctionnel mais qui finalement ressemble à ce que l'on aurait écrit en SQL natif.
    Dans des cas avec jointures nécessaire, il suffit aussi de faire la jointure en "objet" en mettant une clause where avec égalité des 2 clés primaires des objets et s'il y a une table de jointure, Hibernate génèrera la requête SQL adéquate.
    Bref, il n'y a rien de générique ni de magique, tout est régit par le fichier de mapping.
    D'ailleurs, il est possible d'activer les traces SQL afin, notamment lors des tests, de demander à logger les ordres SQL effectivement envoyés.
    Dans ces cas plus complexes, on peut parfois même être étonné de l'ordre généré qui est mieux foutu que ce que l'on imaginait faire "à la main".

  8. #8
    Membre Expert

    Homme Profil pro François Durand
    Spécialiste Delivery Mainframe IBM
    Inscrit en
    octobre 2005
    Messages
    1 219
    Détails du profil
    Informations personnelles :
    Nom : Homme François Durand
    Âge : 55
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Spécialiste Delivery Mainframe IBM
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 219
    Points : 2 079
    Points
    2 079

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    Que veux-tu dire par "visibilité du sql généré" ?
    La possibilité de voir ce code ou d'intervenir dessus ?
    Les deux mon général ...

    Pour le reste, un DBA pourra en analysant la charge du SGBDR définir de nouveaux index ou vue pour optimiser les temps de réponses.
    Nous on préfère voir les principaux accès avant ... On fait du préventif plutôt que du curatif ... Même si l'un n'exclut pas l'autre ...

  9. #9
    Expert Confirmé
    Avatar de GLDavid
    Inscrit en
    janvier 2003
    Messages
    2 683
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 683
    Points : 2 623
    Points
    2 623

    Par défaut

    Bonjour

    Je n'ai pas apporté de réponses.
    Et pour cause, je suis, entre autre, DBA PostgreSQL au sein de la société pour laquelle je bosse (société de consultance en bioinformatique en Belgique).
    Je n'ai pas d'avis concernant ces solutions de mapping ER->Objets. Je reste encore attaché au SQL et c'est le cas pour les développeurs. On se débrouille plutôt bien en SQL.
    Pour le moment, nous ne voyons pas ce que ces API peuvent nous apporter. Manque de connaissance ? Certainement. Il n'empêche que pour le moment, nos clients ne nous demandent pas ces outils. Remarquez que nos clients partent du principe que peu importe le vin tant qu''ils aient l'ivresse. En clair, on a carte blanche sur les outils (tant que ça matche avec leur infra-structure). En interne à présent, étant DBA, je ne suis pas hostile à l'utilisation de ces outils. Je ne demande qu'à voir ce que ça peut apporter de plus. Si ça permet un gain de rapidité par rapport à une requête SQL, pourquoi pas.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  10. #10
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 843
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 843
    Points : 2 929
    Points
    2 929

    Par défaut

    Mais l'objectif n'est pas d'aller "plus vite" côté SQL
    C'est de fournir un niveau d'abstraction plus élevé que SQL pour écrire des requêtes vers la base. On utilise les même termes qu'au niveau objet et c'est le framework qui fait la traduction.
    C'est vrai que le framework apporte des éléments pour les perfs comme les caches de premier et second niveau mais je dirai que l'essentiel n'est pas là.
    C'est comme quand on a inventer le C afin de ne plus écrire de l'assembleur, l'idée première était de permettre d'écrire plus facilement.
    Côté base de données, quand on a des problèmes de perfs, c'est plus à cause d'une mauvaise conception du code et de la base elle-même qu'à cause des requêtes elles-mêmes.

  11. #11
    Expert Confirmé
    Avatar de GLDavid
    Inscrit en
    janvier 2003
    Messages
    2 683
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 683
    Points : 2 623
    Points
    2 623

    Par défaut

    Hello

    Citation Envoyé par ego Voir le message
    Mais l'objectif n'est pas d'aller "plus vite" côté SQL
    C'est de fournir un niveau d'abstraction plus élevé que SQL pour écrire des requêtes vers la base. On utilise les même termes qu'au niveau objet et c'est le framework qui fait la traduction.
    C'est vrai que le framework apporte des éléments pour les perfs comme les caches de premier et second niveau mais je dirai que l'essentiel n'est pas là.
    C'est comme quand on a inventer le C afin de ne plus écrire de l'assembleur, l'idée première était de permettre d'écrire plus facilement.
    Côté base de données, quand on a des problèmes de perfs, c'est plus à cause d'une mauvaise conception du code et de la base elle-même qu'à cause des requêtes elles-mêmes.
    Merci pour ces infos mais je n'ai jamais dit que ça permettait d'aller plus vite côté SQL. J'ai bien compris qu'on s'affranchit du SQL mais que ça n'accélerait pas les requêtes SQL. C'est une autre manière d'interroger la base.
    Maintenant, tu mentionnes que cette solution apporte un niveau d'abstraction. Mouais... Franchement, il me semble que la création des tables et le fait de produire un schéma relationnel est déjà une abstraction. Autre chose, si ces frameworks miment les tables en objets, dites, pour des grosses bases de données (>100 tables) votre application doit grossir méchamment, non ?
    Bref, j'attends plus d'être convaincu par ces frameworks. Je comprends que des gens soient fâchés par SQL mais à mon humble avis, c'est pas demain la veille que vous vous débarasserez du langage qui a permis d'interroger clairement une base.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  12. #12
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    J'aime beaucoup SQL, je n'ai rien à lui reprocher en tant que langage de requête, mais l'intérêt d'un orm n'est pas là.
    L'orm permet une meilleure isolation entre les données manipulées par l'application et la base de données. On passe d'une base de données Oracle à une DB2 ou MySQL sans l'ombre d'une modification.
    Un autre avantage de l'orm est la possibilité d'avoir une classe unique (dérivée) pour les opérations CRUD (strictement rien de spécifique à coder grâce aux génériques (vive java 1.5 !)
    Pour ce qui est de l'extraction des données, les query proprement dit, on peut faire autant de chose qu'en SQL, on raisonne en propriété de la classe plutôt qu'en jointure mais globalement, lorsqu'on consulte le SQL généré, on n'aurait que très rarement écrit autre chose "à la main".
    Ensuite il y a le gros avantage des propriétés "lazy loadées". C'est tout de même super intéressant d'avoir la possibilité de définir un graphe d'objets et de se dire qu'on n'exécutera la requête d'extraction que si l'objet est demandé explicitement, plus loin dans les couches de l'application. Dans ce cas, effectivement, une nouvelle requête est lancée (qui coûtera du temps, c'est clair) mais au moins, elle ne sera lancée QUE si on en a besoin.
    Et rien n'empêche l'application si besoin d'influer à la demande sur le chargement tardif pour éviter cela.
    Bref, surtout des avantages, que peux d'inconvénients...

  13. #13
    Expert Confirmé
    Avatar de GLDavid
    Inscrit en
    janvier 2003
    Messages
    2 683
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 683
    Points : 2 623
    Points
    2 623

    Par défaut

    Hello

    Citation Envoyé par OButterlin Voir le message
    J'aime beaucoup SQL, je n'ai rien à lui reprocher en tant que langage de requête, mais l'intérêt d'un orm n'est pas là.
    L'orm permet une meilleure isolation entre les données manipulées par l'application et la base de données. On passe d'une base de données Oracle à une DB2 ou MySQL sans l'ombre d'une modification.
    Un autre avantage de l'orm est la possibilité d'avoir une classe unique (dérivée) pour les opérations CRUD (strictement rien de spécifique à coder grâce aux génériques (vive java 1.5 !)
    Pour ce qui est de l'extraction des données, les query proprement dit, on peut faire autant de chose qu'en SQL, on raisonne en propriété de la classe plutôt qu'en jointure mais globalement, lorsqu'on consulte le SQL généré, on n'aurait que très rarement écrit autre chose "à la main".
    Ensuite il y a le gros avantage des propriétés "lazy loadées". C'est tout de même super intéressant d'avoir la possibilité de définir un graphe d'objets et de se dire qu'on n'exécutera la requête d'extraction que si l'objet est demandé explicitement, plus loin dans les couches de l'application. Dans ce cas, effectivement, une nouvelle requête est lancée (qui coûtera du temps, c'est clair) mais au moins, elle ne sera lancée QUE si on en a besoin.
    Et rien n'empêche l'application si besoin d'influer à la demande sur le chargement tardif pour éviter cela.
    Bref, surtout des avantages, que peux d'inconvénients...
    Ta description est bien faite et je te remercie de cette réponse intéressante. Je le vois alors plus comme un outil pour développeur, pas tellement pour DBA. Si ça peut vous aider sans vous contraindre à des requêtes SQL parfois compliquée, je peux comprendre l'approche. Tout est question de goût et si un développeur préfère cette approche plutôt que du SQL pour faire un query, je ne rien qui m'empêcherait de lui autoriser un tel accès.
    Mais, de mon côté DBA, vous comprendrez que je n'ai pas trop l'utilité de ces outils. Par contre, je l'accepterai du côté développeur seulement pour des queries type SELECT.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  14. #14
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    Citation Envoyé par GLDavid Voir le message
    Mais, de mon côté DBA, vous comprendrez que je n'ai pas trop l'utilité de ces outils. Par contre, je l'accepterai du côté développeur seulement pour des queries type SELECT.
    C'est dommage, d'un point de vue gain de développement c'est surtout sur la partie CRUD qu'on gagne...
    Dans la mesure où la partie requêtes est généralement spécifique à l'ihm (ou à la fonction), on est là plus proche des requêtes sql natives (avec le lazy loading en moins)...

    Je dirais que pour la "Gestion" d'un enregistrement db, il est plus rare de ne vouloir mettre à jour qu'une seule colonne (ou un jeu de colonnes), donc limiter l'usage d'un CRUD n'est pas trop justifiée. (je ne dis pas que le cas ne se présente pas, l'évolution d'un statut en est un parfait exemple)
    Cette limite est vraie surtout pour la mise à jour, un peu pour la création, et pas du tout pour la suppression... pourquoi se priver pour si peu...

  15. #15
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 294
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 294
    Points : 27 313
    Points
    27 313

    Par défaut

    Voici la référence intégrale de l'article postée sur le monde informatique, que je dois mettre sous developpez avec quelques éléments supplémentaires :
    http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  16. #16
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Voici la référence intégrale de l'article postée sur le monde informatique, que ej dois mettre sous developpez avec quelques éléments supplémentaires :
    http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

    A +
    Hormis le point de vue sexiste sur le sac à main des femmes qui va sûrement en froisser plus d'une, je me permets également de signaler que certaines affirmations sont incomplètes.
    Par exemple :

    1- Peut-on modifier les données à partir d'une vue : tu dis oui

    je dis non quand il s'agit d'une jointure, dans la majorité des cas... on ne peut modifier les données que d'une seule des tables de jointure, l'insert ne passe pas, le delete non plus

    2- Les données sont plus importantes que le programme

    vaste débat... les images numériques sont un bon support pour illustrer.
    Une image numérique est une suite de 0 et de 1. De ton point de vue, le plus important est de les sauvegarder (certes).
    Mais si on retrouvait ces données dans quelques années et que le format n'ait pas été documenté, on se retrouverait dans l'incapacité de reconstituer l'image.
    Bon, je dois reconnaître que tu parles de documenter l'accès aux données, ce qui pourrait inclure un schéma des données.

    A part ça, j'aime beaucoup l'article, un peu moins le côté "sectaire" de l'approche. Ceci dit, les 2 camps font pareil...
    Il y a quelques années, j'avais tendance à pousser dans ce sens, à grand coup de trigger (ô apparition divine avec la V2 de l'OS/400 et DB2).
    Depuis, les contraintes des ssii sont passées par là et l'avis est plus... mitigé...
    Je reste convaincu que d'un point de vue performance, la procédure stockée sera largement plus performante qu'une suite de mise à jour pilotées par l'application... Pour autant, il faudra passer tous les arguments à la dite procédure, ce qui la rendra plus difficile à maintenir (d'autant qu'aucune erreur ne pourra être détectée avant l'exécution)

    Bref, il y a du bon dans les 2 approches, pour moi, ce sont les contraintes de l'application qui permettront de se déterminer.
    Je te suis également sur un autre aspect, il y a effectivement une carence dans les formations actuelles... trop "haut niveau"...

    Encore une fois, globalement, bon article...

  17. #17
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 294
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 294
    Points : 27 313
    Points
    27 313

    Par défaut

    1- Peut-on modifier les données à partir d'une vue : tu dis oui

    je dis non quand il s'agit d'une jointure, dans la majorité des cas... on ne peut modifier les données que d'une seule des tables de jointure, l'insert ne passe pas, le delete non plus
    Malheureusement votre remarque est fausse et prouve la méconnaissance relative aux bases de données.... En effet depuis un dizaine d'années, les tiggrers INSTAED OF sont apparus et permettent de faire ce que justement les ORM ne mettent hélas jamais en œuvre, du mapping RO à l'intérieur du SGBDR

    Démonstration :

    La base de la démo :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    CREATE TABLE T_PERSONNE
    (PRS_ID         INT NOT NULL PRIMARY KEY,
     PRS_NOM        VARCHAR(32) NOT NULL);
    GO
     
    CREATE TABLE T_PERSONNE_PRENOM
    (PRS_ID         INT NOT NULL,
     PSP_POSITION   SMALLINT NOT NULL,
     PSP_PRENOM     VARCHAR(16) NOT NULL,
     CONSTRAINT PK_PRS PRIMARY KEY (PRS_ID, PSP_POSITION),
     CONSTRAINT FK_PRS FOREIGN KEY (PRS_ID) REFERENCES T_PERSONNE (PRS_ID));
    GO
    La vue avec jointure

    Code :
    1
    2
    3
    4
    5
    6
    7
    CREATE VIEW V_PERSONNE
    AS
    SELECT P.PRS_ID, PRS_NOM, PSP_POSITION, PSP_PRENOM
    FROM   T_PERSONNE AS P
           INNER JOIN T_PERSONNE_PRENOM AS PP
                 ON P.PRS_ID = PP.PRS_ID;
    GO
    Le déclencheur INSERT sur la vue :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    CREATE TRIGGER E_I_PERSONNE
    ON V_PERSONNE
    INSTEAD OF INSERT
    AS
       INSERT INTO T_PERSONNE
       SELECT PRS_ID, PRS_NOM
       FROM   inserted AS i
       WHERE  i.PRS_ID NOT IN (SELECT PRS_ID 
                               FROM   T_PERSONNE);
     
       UPDATE T_PERSONNE
       SET PRS_NOM = i.PRS_NOM
       FROM   inserted AS i
       WHERE  i.PRS_ID IN (SELECT PRS_ID 
                           FROM   T_PERSONNE);
     
       INSERT INTO T_PERSONNE_PRENOM
       SELECT PRS_ID, 
              COALESCE(PSP_POSITION, (SELECT MAX(PSP_POSITION) + 1
                                      FROM   T_PERSONNE_PRENOM AS PP
                                      WHERE  PP.PRS_ID = i.PRS_ID)),
              PSP_PRENOM
       FROM   inserted AS i;
    GO
    Un petit essai :

    Code :
    1
    2
    INSERT INTO V_PERSONNE VALUES (1, 'Dupont', 1, 'Marcel')
    INSERT INTO V_PERSONNE VALUES (1, 'Dupont', NULL, 'Théophile')
    Le test :

    Code :
    1
    2
    3
    SELECT * FROM V_PERSONNE
    SELECT * FROM T_PERSONNE
    SELECT * FROM T_PERSONNE_PRENOM
    Le résultat :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    PRS_ID      PRS_NOM                          PSP_POSITION PSP_PRENOM
    ----------- -------------------------------- ------------ ----------------
    1           Dupont                           1            Marcel
    1           Dupont                           2            Théophile
     
    (2*ligne(s) affectée(s))
     
    PRS_ID      PRS_NOM
    ----------- --------------------------------
    1           Dupont
     
    (1*ligne(s) affectée(s))
     
    PRS_ID      PSP_POSITION PSP_PRENOM
    ----------- ------------ ----------------
    1           1            Marcel
    1           2            Théophile
    CQFD....

    Moralité :
    1) les gens oublient toujours l'importance des vues
    2) les gens ne sont pas formés à faire du mapping RO au sein du SGBDR !

    mais il est vrai qu'un pseudo SGBDR comme MySQL ne sait pas faire ce genre de chose... En revanche DB2, Oracle ou SQL Server savent faire cela depuis des années !!!!


    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  18. #18
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 546
    Points : 6 169
    Points
    6 169

    Par défaut

    Ok en passant par un trigger, mais de base, on ne peut pas faire d'insert ou d'update sur une vue.
    Au minimum il faut préciser "on peut avec un trigger" plutôt que d'être péremptoire...

  19. #19
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 843
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 843
    Points : 2 929
    Points
    2 929

    Par défaut

    Maintenant, tu mentionnes que cette solution apporte un niveau d'abstraction. Mouais... Franchement, il me semble que la création des tables et le fait de produire un schéma relationnel est déjà une abstraction
    Ben si, le niveau d'abstraction est non seulement plus haut qu'ne manipulant les noms des tables et colonnes mais en plus, on est homogène par rapport au reste du code qui lui manipule les concepts objets.
    Comme tu l'as dit, c'est plus un outil de développeur qu'un outil de DBA.

    Je comprend le besoin de connaitre les requêtes qui vont être exécutées pour optimiser la base mais franchement, on ne fait que rarement des requêtes compliquées quand on navigue dans un modèle objet. Les requêtes HQL (cas d'Hibernate) sont pratiquement identiques au SQL.
    On peut dans tous les cas demander les "log SQL" afin de connaitre les requêtes exécutées. On fait cela pendant les tests et s'il y a un problème grave on peut toujours forcer une requête X ou Y en la codant en dur dans les fichiers de configuration.

    Bref, je ne vois vraiment pas quelles peuvent être les réticences si ce n'est de la méconnaissance de l'outil.


    NB : et concernant le nombre de tables, ça n'a aucune influence; on ne remonte pas toute la base. Là, je ne vois pas le problème encore.

  20. #20
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 843
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 843
    Points : 2 929
    Points
    2 929

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Puisqu'on parle de ce bon vieux Mainframe et que c'est mon domaine professionnel, je vais ajouter une modeste contibution au présent débat en citant un "gourou" en matière de SGBD sur le Mainframe (DB2 z/OS), à savoir Susan Lawson, qui sait de quoi elle parle :

    Canonical Database Architecture and DB2 Performance ... Really ?

    Sans recouper totalement l'article de SQLpro, on peut noter quand même quelques points de convergence.

    Quelques morceaux choisis :



    Il va sans dire que je partage totalement ce point de vue ...
    Mais rien dans tout cela ne milite contre les ORM !
    Comme je l'ai mentionné, il ne s'agit pas d'accès génériques mais de facilité d'écriture de la requête.
    Si pour un besoin précis on veut ne remonter que partiellement un objet stocké dans une table, par exemple, on peut écrire un truc du genre :

    Code :
    select new ClientPartiel(nom,prenom,date naissance) from Client where ....
    Sachant que ce qui est décrit dans le fichier de mapping est la classe Client "totale".
    Bref, les ORM sont très très ouverts et permettent, quand on sait s'en servir (mais c'est comme tout, hein !?), de faire ce qui est le plus adapté.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •