IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Affichage des résultats du sondage: Êtes-vous pour l'utilisation d'un ORM (mapping objet-relationnel) ? Pourquoi ? Partagez vos avis

Votants
116. Vous ne pouvez pas participer à ce sondage.
  • Oui

    60 51,72%
  • Non

    54 46,55%
  • Pas d'avis

    4 3,45%
Sondage à choix multiple
Langage SQL Discussion :

Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ?


Sujet :

Langage SQL

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    Juin 2016
    Messages
    3 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2016
    Messages : 3 160
    Points : 66 249
    Points
    66 249
    Par défaut Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ?
    Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ?
    Eli Bendersky donne son avis

    L’arrivée des ORM pour les langages de programmation a apporté un certain nombre d’avantages s’agissant de la manipulation et la modification de données dans la construction d’une application. Un ORM (Object Relational Mapping) est un ensemble de librairies qui vous permettent d’interagir d’une manière plus simple avec vos données à travers des objets. Autrement dit, il s’agit d’un programme informatique qui se place en interface entre un programme applicatif et une base de données relationnelle pour simuler une base de données orientée objet. De ce fait, faut-il en utiliser un ou faut-il simplement écrire toutes ses requêtes à la base données avec le langage SQL ?

    Il s’agit en effet d’un débat qui s’installe très souvent entre les développeurs. Les ORM sont venus avec pour vocation : la réduction du code à écrire et à maintenir pour l’informaticien qui manipule la base de données depuis son logiciel, l’homogénéité du code objet et l’accélération du temps de développement. Néanmoins, bien que ces avantages semblent très souvent les plus recherchés par les développeurs, les spécialistes des bases de données leur trouvent beaucoup de défauts. On pourrait insinuer que les développeurs y voient surtout une simplification et une accélération de leur temps de développement, mais la bonne pratique des ORM est certainement dans une utilisation modérée et circonstanciée de ces outils.

    Selon Eli Bendersky, programmeur et contributeur à l’open source, les ORM, malgré les avantages qu’on peut leur citer, sont limités lorsqu’il s’agit de travailler sur des modèles de bases de données plus complexes que le classique CRUD. Son analyse s’est basée sur une comparaison de l’utilisation du SQL simple et ensuite d’un ORM pour manipuler une base de données d'une application écrite avec le langage de programmation Go. Il a tiré la conclusion selon laquelle l’utilisation ou non d’un ORM dépend des avantages des dépendances supplémentaires en fonction de l’effort. En d’autres termes, cela a-t-il un sens d'implémenter vous-même presque toutes ou toutes les fonctionnalités d'un projet, ou est-il préférable d'utiliser la pléthore de bibliothèques disponibles pour de nombreuses sous-tâches que le projet doit effectuer ?

    Nom : d7585-10yxhekcxw8ij5k2wft1oow.png
Affichages : 36367
Taille : 10,1 Ko

    D’après ce qu’explique Bendersky, les avantages des ORM résident principalement dans la réduction du code à écrire, ce qui les laisse avec un lot considérable d’inconvénients. Pour lui, les ORM évitent un codage fastidieux. Ils vous font faire environ 50 % d’économie en code centré sur la base de données, ce qui n’est pas banal et peut faire une réelle différence pour certaines applications. Les autres avantages qu’on peut citer pour les ORM sont plus remarquables avec la plupart des applications simples, mais lorsqu’il s’agit de schémas de bases de données plus complexes ou d’applications avec des niveaux d’abstractions plus avancées, les ORM montrent tout de suite leurs limites.

    Par exemple, certains avancent qu'ils ne permettent pas de gérer les requêtes un peu complexes (jointures, groupements), les transactions ou les traitements par lots et parfois, les relations many-to-many sont également difficiles à gérer. Ils créent en plus une forte dépendance à l’outil ORM utilisé. En général, ils causent des problèmes lorsque la base de données n’est pas faite dans les règles de l’art. Dans son cas, Bendersky a utilisé l’ORM Gom pour le langage de programmation Go, qui selon lui présente les mêmes inconvénients. Après son analyse comparative, il a noté les inconvénients suivants liés aux ORM :

    • une autre couche à apprendre, avec toutes les particularités, la syntaxe spéciale, les balises magiques, etc. Ceci est principalement un inconvénient si vous êtes déjà familiarisé avec SQL lui-même ;
    • même si vous n'avez pas l'habitude d'utiliser SQL, il existe une vaste banque de connaissances et de nombreuses personnes pouvant vous aider à trouver des réponses. Tout ORM est un savoir beaucoup plus obscur que beaucoup ne partagent pas, et vous passerez beaucoup de temps à chercher comment forcer les choses ;
    • déboguer les performances des requêtes est un défi, car l’abstraction se trouve à un niveau plus éloigné du métal. Il faut parfois un peu de peaufinage pour que l'ORM génère les requêtes qui vous conviennent, ce qui est frustrant lorsque vous connaissez déjà les requêtes dont vous avez besoin.

    Enfin, dit-il, il existe un inconvénient qui ne devient apparent qu'à long terme. Il estime que le SQL reste à peu près constant au fil des ans, mais les ORM sont spécifiques à la langue et tendent également à apparaître et à disparaître tout le temps. Chaque langage populaire dispose d’une grande variété d’ORM. Lorsque vous passez d'une équipe/entreprise/projet à un autre, vous pouvez être amené à changer de fournisseur, ce qui constitue un fardeau mental supplémentaire. Ou vous pouvez changer complètement de langue. Pour lui, le SQL est une couche beaucoup plus stable qui vous accompagne dans vos équipes/langages/projets et ceci, peu importe les circonstances.

    Enfin, il finit en réitérant que l’attrait le plus important des ORM est la réduction du code passe-partout, mais mis à part cela, dit-il, il existe de nombreux inconvénients à utiliser un ORM. Selon lui, les langages de programmation comme le langage Go font aujourd’hui l’effort de proposer un bon interfaçage avec le SQL. Il faudrait donc éviter les dépendances inutiles aux ORM ou à d’autres bibliothèques au risque de perdre la fluidité voulue pour son projet. « Je ne pense pas qu’un ORM me soit utile dans un langage comme Go, qui possède déjà une bonne interface SQL, principalement portable sur les bases de données. Je préférerais passer un peu plus de temps à taper mes requêtes, mais cela me fera gagner en performance après. Mes requêtes seront optimisées et, plus important encore, le débogage sera plus facile à effectuer », a-t-il déclaré.

    De même, selon certains, les gains de productivité (du moins au tout début du développement) avec l’utilisation d’un ORM sont indéniables. Par contre, a écrit l’un d’entre eux, « ce que j'ai toujours recherché, ce sont des frameworks qui vous donnent un ORM mais rendent aussi les requêtes de bas niveau très faciles, normalement à travers un constructeur de requêtes et vous permettant de passer d'un niveau d'abstraction à un autre. Si je devais choisir, je préfère les bibliothèques qui vous donnent d’abord le niveau le plus bas d’abstractions, puis s’appuient sur celles-ci pour offrir une approche ORM basée sur la programmation orientée objet (ce à quoi, selon moi, la plupart des gens pensent quand on dit “ORM”) ». Il cite TypeORM comme l’une des meilleures bibliothèques qu’il a utilisées.

    Mais dans le même temps, un autre indique que TypeORM avait été écrit par des personnes qui ne connaissaient pas vraiment le SQL. Pour lui, les ORM sont excellents pour les tâches répétitives, en particulier lorsqu'ils sont intégrés à des frameworks. Cependant, dit-il, la présence d’un ORM peut empêcher le plus souvent d'accéder aux aspects les plus avancés d’une base de données.

    Source : Billet de blog

    Et vous ?

    Quel est votre avis sur le sujet ?
    Devrait-on continuer d'utiliser les ORM, selon vous ? Pourquoi ?

    Voir aussi

    Prisma, un outil ORM pour le développement des applications modernes. Pourra-t-il remplacer les outils ORM traditionnels ?

    L'ORM serait-il une « grosse erreur » ? Selon un développeur, « l'ORM est un anti-pattern qui ne devrait pas exister »

    « ORM or not ORM » : faut-il les utiliser ou continuer d'écrire simplement des requêtes SQL ?
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités
      14  1

  2. #2
    Membre émérite
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2009
    Messages : 901
    Points : 2 804
    Points
    2 804
    Par défaut
    Pour moi les ORM excellent dans les points suivants :

    • Opération d'écriture => pas de SQL à faire nous-même => gros gain de temps.
    • Cache : le cache transactionnel permet de séparer les développements tout en évitant le double requêtage de certain élément s'il sont déjà chargés par l'ORM


    Les points à surveiller sont les suivants :

    • Ne pas vouloir charger trop de données d'un coup ou pas assez, et donc ne pas tirer parti du cache ou faire exploser la RAM.
    • Cache inter-transaction : faire attention avec cela.
    • Recherche : on peut faire des choses relativement puissantes, surtout pour aller de paire avec des filtrages typiques d'écran de recherche.


    Je mets les éléments suivants à part :

    • Performance de base (N+1 select, traitement prs batch typiquement) => manque de compétence (ou d'un guide) du développeur sur l'outil plutôt qu'autre chose.
    • Requêtage complexe : je ne pense pas que les ORM avaient prévu (et c'est toujours le cas) de remplacer le SQL dans tous les cas d'utilisation. Il faut donc faire preuve de jugement et passer au SQL quand c'est nécessaire. Par exemple, les requêtes récursives sont possibles en SQL, autant s'en servir s'il le faut.
    • En Java par exemple certains éléments d'ORM ne sont pas 100% compatibles sur les SGBD : il s'agit de problème de Driver JDBC, pas des ORM.
      6  0

  3. #3
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    729
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 729
    Points : 1 414
    Points
    1 414
    Par défaut
    Avouons que, la plupart du temps, le problème ne vient pas de l'outil, mais de la méthode.
    Et pour être plus exact de la qualité de ce comment la "conception" est menée.

    Pour avoir un ORM il faut un modèle objet.
    Or, comment est conçu ce modèle ?
    La plupart du temps : "à l'arrache"
    Quelle est la portée du modèle ?
    La plupart du temps : "limitée au développement"

    Franchement quand on a dépassé ça, on a franchi un grand pas.

    Je suis sidéré par le silence (ou par les tentatives de détournement d'attention) lorsqu'on demande à consulter les documents "conceptuels" (diagrammes UML, MCD, ...)
    Un peu comme le cahier des charges ; tout le monde en parle, personne ne l'a lu

    La doxa du moment est de développer toujours, et encore, plus vite.
    Tout faire "pour hier", sans répits, sans documentation, sans partages, sans contradictions, ne peut pas aller dans le sens de la qualité.
    Le savoir est une nourriture qui exige des efforts.
      5  1

  4. #4
    Membre expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    Mars 2007
    Messages
    592
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur d'applications métier
    Secteur : Service public

    Informations forums :
    Inscription : Mars 2007
    Messages : 592
    Points : 1 679
    Points
    1 679
    Par défaut
    Comme déjà indiqué ci-dessus, il faut savoir prendre différents outils selon les circonstances :
    - Mapping ORM pour les opérations CRUD de base, pour ne pas créer de requêtes basiques, qui n'apportent pas de valeur ajoutée, et faciliter les évolutions des modèles de données,
    - requêtes sur-mesure pour tout ce qui ressort des requêtes un peu évoluées, avec optimisation si besoin.

    ça nécessite juste les compétences nécessaires pour ce métier, et savoir choisir les bons outils (dédicace à un de mes anciens formateurs)
      2  1

  5. #5
    Membre expérimenté
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    Juillet 2008
    Messages
    414
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : Juillet 2008
    Messages : 414
    Points : 1 508
    Points
    1 508
    Par défaut Une nouvelle surcouche
    Je travaille sur le maintien en conditions opérationnelles d'un logiciel ancien. Tellement ancien que l'archivage automatique est en PLS depuis 5 ans. Il y a une couche logicielle entre la BDD et le produit. Le nombre de données à archiver est tellement important qu'à chaque tentative de purge, la couche logicielle fait un memory full. J'ai donc demandé à mon équipe de développement de ré-écrire la fonction de purge en pure SQL. Voilà...
      3  0

  6. #6
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    Mai 2002
    Messages
    9 080
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 9 080
    Points : 30 778
    Points
    30 778
    Par défaut
    Utiliser un ORM, pourquoi pas ? Mais surtout commencer par former correctement les développeurs Java à l'écriture des requêtes et au fonctionnement sous-jacent d'un SGBD.
    Non, ce n'est pas plus simple de filtrer les lignes dans le code Java. Ca encombre juste inutilement le réseau.
    Non, ce n'est pas plus efficace d'effectuer les vérifications de validité dans le code Java. Ca permet juste de laisser la capacité d'enregistrer des données invalides dans la base de données.
    Non, ce n'est pas utile de calculer des totaux dans le code Java pour les enregistrer dans la table. C'est seulement une manière de riquer à terme d'avoir une information calculée stockée différente du contenu réel des données.
    On calcule l'âge du prospect au moment de son enregistrement dans la base. Ca ira plus vite que de le calculer à chaque fois qu'on en a besoin...
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.
      11  1

  7. #7
    Modérateur

    Avatar de MaitrePylos
    Homme Profil pro
    DBA
    Inscrit en
    Juin 2005
    Messages
    5 496
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA
    Secteur : Service public

    Informations forums :
    Inscription : Juin 2005
    Messages : 5 496
    Points : 12 596
    Points
    12 596
    Par défaut
    Le souci, n'est pas vraiment l'utilisation d'un orm, mais bien la conceptualisation de la db (MCD, MLD).
    Car si l'application deviendra obsolète les données seront toujours utile.
    Je migre une source de données de 1998 et je pleure tous les jours
      4  0

  8. #8
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    SQL est un reliquat d'une autre époque et il est très compliqué de faire un code compréhensible et réutilisable. Donc ORM à 100%, il serait temps que les bases de données évoluent en rentrent dans le 21e siècle.
      1  24

  9. #9
    Modérateur

    Avatar de MaitrePylos
    Homme Profil pro
    DBA
    Inscrit en
    Juin 2005
    Messages
    5 496
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA
    Secteur : Service public

    Informations forums :
    Inscription : Juin 2005
    Messages : 5 496
    Points : 12 596
    Points
    12 596
    Par défaut
    Citation Envoyé par Sodium Voir le message
    SQL est un reliquat d'une autre époque et il est très compliqué de faire un code compréhensible et réutilisable. Donc ORM à 100%, il serait temps que les bases de données évoluent en rentrent dans le 21e siècle.
    Sauf que les ORM font des requêtes SQL
      7  1

  10. #10
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    Tout comme le code devient du binaire, personnellement je préfère utiliser un code propre et compréhensible plutôt que du binaire

    Sql est un peu l'assembleur des BDDs tout comme JavaScript est l'assembleur du web côté client.
      1  18

  11. #11
    Nouveau membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2019
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2019
    Messages : 12
    Points : 39
    Points
    39
    Par défaut
    Voilà plus de 5 ans que je suis "abonné" à developpez.net sans jamais m'être inscrit(**t'aurais du le rester)... Mais les récents post et leurs commentaires associés suscitent un accueil de moins en moins "chaleureux" de ma part.

    Je vais commencer par un jugement de valeur sur l'avis de M. Eli Bendersky:

    Lorsque je constate que les langages de programmation et ORMs choisis comme base de comparaison et/ou fer de lance de la famille des ORMs sont respectivement Go + TypeScript et Gom + TypeORM, alors je me demande si je dois gerber ou raler.
    Voici plus d'un an que je code en TypeScript côté Back(NestJS), et je peux vous dire que typeorm est mieux que l'éditeur de requête SQL basique(knexJS), indépendamment de la complexité du système; cependant, mon expérience avec l'ORM de django est à des années lumières du reste en terme de plaisir d'utilisation et d'efficacité. J'ai le même retour venant des utilisateurs(mes amis & collègues) d'Active Record(Ruby - Rail), ainsi que que des utilisateurs d'Entity Framework.

    Comme d'habitude, dans mon entourage proche, les ORMs Java marchent bien, mais sont très critiqués pour leur lourdeur.

    En outre, lors du test de prisma(orm extrêment prométeur) avec Go, j'ai eu l'impression de traîner un boulet .
    Mon opinion sur Go est assez catégorique et peut-être biaisée; écrire du code business avec Go c'est presque pareil que de le faire en C.

    Enfin, un jugement plus factuel et technique:

    Avoir des connaissances sur la base de données choisie pour le développement de votre application:
    - Relationnelle? Orienté document? Graphe? Entrepôt? Qu'est ce qui correspond le mieux à vos besoins?
    - Comprendre la notion de transaction.
    - Développer le bon sens dans la construction des requêtes(optimiser en fonctions de son modèle de données, utiliser correctement les alias...).
    - savoir si vos requêtes sont optimisées automatiquement par le moteur de calcul de l'ORM.
    - connaître les stratégies de caching de requêtes proposées par l'ORM.
    - savoir quel driver vous utilisez: est-ce qu'il génère des requêtes textuelles destinées à être réinterprétées par l'engine de la DB ou bien des requêtes sérialisées...

    Orm ou pas, l'idée est:
    - d'en apprendre toujours plus sur les outils mis à notre disposition,
    - pour produire des solutions de qualité à nos problèmes (CRUD, traitement, maladie, mariage, etc ...)
      3  1

  12. #12
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Ecrire directement des requêtes SQL sans passer par un ORM pose deux gros problèmes :
    • Chaque SGBD a son propre dialecte non standard de SQL.
    • Assembler des morceaux de requêtes SQL n'est pas pratique.


    Comme exemple d'ORM, prenons celui du framework Django de Python.

    Extrait de la documentation :
    Example:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Entry.objects.get(title__iregex=r'^(an?|the) +')
    SQL equivalents:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    SELECT ... WHERE title REGEXP '^(an?|the) +'; -- MySQL
     
    SELECT ... WHERE REGEXP_LIKE(title, '^(an?|the) +', 'i'); -- Oracle
     
    SELECT ... WHERE title ~* '^(an?|the) +'; -- PostgreSQL
     
    SELECT ... WHERE title REGEXP '(?i)^(an?|the) +'; -- SQLite
    Ici, passer par un ORM permet de changer plus facilement de SGBD, car il n'y a pas besoin de réécrire la requête.

    Autre exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Entry.objects.filter(pub_date__year=2005).order_by('-pub_date', 'headline')
    Dans le code ci-dessus, Entry.objects est un objet de type QuerySet.
    La méthode QuerySet.filter retourne un nouveau QuerySet qui contient un filtre en plus.
    La méthode QuerySet.order_by retourne un nouveau QuerySet qui contient un tri en plus.
    C'est uniquement lorsqu'on essaie de parcourir le QuerySet final que ce dernier est converti en requête SQL et que cette dernière est exécutée.
    Du coup, on peut voir la classe QuerySet comme un morceau de requête SQL que l'on peut compléter au fur et à mesure en appelant des méthodes de la classe QuerySet. On peut alors faire ce genre de chose dans le code Python :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    query_set = Entry.objects
    if condition_1:
        query_set = query_set.filter(pub_date__year=2005)
    if condition_2:
        query_set = query_set.order_by('-pub_date', 'headline')
    Cependant, lorsqu'on a besoin de fonctionnalités avancées qui ne sont pas supportées par l'ORM de Django, il faut écrire les requêtes SQL à la main.

    Sodium a raison de dire que SQL est un reliquat d'une autre époque et que c'est un peu l'assembleur des SGBD.
    Il faudrait que les ORM continuent de se développer pour qu'on ait de moins en moins souvent besoin d'écrire directement des requêtes SQL.
      3  5

  13. #13
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Sodium a raison de dire que SQL est un reliquat d'une autre époque et que c'est un peu l'assembleur des SGBD.
    Il faudrait que les ORM continuent de se développer pour qu'on ait de moins en moins souvent besoin d'écrire directement des requêtes SQL.
    Ce sont surtout les SGBD qui devraient évoluer et entrer dans la modernité.
    Il paraît que les bdd objet y en a qui ont essayé ils ont eu des problèmes.
    Mais ce n'est pas parce qu'ils se sont plantés qu'il ne faut pas continuer d'avancer. En réfléchissant comme ça on en serait encore à coder avec des cartes poinçonnées.
      1  9

  14. #14
    Modérateur

    Avatar de MaitrePylos
    Homme Profil pro
    DBA
    Inscrit en
    Juin 2005
    Messages
    5 496
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA
    Secteur : Service public

    Informations forums :
    Inscription : Juin 2005
    Messages : 5 496
    Points : 12 596
    Points
    12 596
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Ici, passer par un ORM permet de changer plus facilement de SGBD, car il n'y a pas besoin de réécrire la requête.
    Ha le vieux fantasme de changer de moteur de DB à la volée.
    Si cela est vrai pour des outils de gestion (Drupal, CMS ou autre), c'est à dire des outils qui se veut généraliste.
    Cela est nettement moins vrais pour des outils spécialisé.
      11  1

  15. #15
    Membre éprouvé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Décembre 2008
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2008
    Messages : 106
    Points : 906
    Points
    906
    Par défaut
    L'ORM apporte une facilité d'utilisation, une indépendance par rapport à la BD sous-jacente et un modèle objet. Par contre, cela se fait au détriment de la performance: l'ORM crée une requête SQL sur laquelle on n'a pas de contrôle, si elle n'est pas optimisée l'exécution s'en ressentira. De plus une requête SQL retourne une ligne qui est mappée dans des variables, l'ORM rajoutera en plus la création d'un objet pour recevoir les données..
    Si votre objectif est la performance (traitement d'un grand jeu de données), il est préférable de rester sur du SQL: vous aurez plus de points de contrôle (notamment avec le plan d'exécution)... Si votre objectif est de ne pas se soucier de la BD et d'avoir une maintenance simplifiée, l'ORM présente des avantages indéniables...
      7  0

  16. #16
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 851
    Points : 2 424
    Points
    2 424
    Par défaut
    ca fait quelques projets from scrap que j'utilise jpa avec hivernate, le prochain n'utilisera aucun orm.

    Je suis partout de 0 il y a environ 5 ans niveau orm et je trouve que le gain n'est pas si énorme en terme d'économie de temps.

    De tout façon faut tout valider les requêtes qui sont généré derrière, faire les optimisations.
    Selon le cas, tu veux qu'une structure objet soit fetché... afin de ne pas avoir le problème des requête n+1.

    Il y a quand même beaucoup de bug, suffit de voir hibernate, les cas complexes ne sont pas toujours possible et nécessite de faire du natif.

    Ils ne supporte pas toujours des framework dit reactive.

    Je pense utilisé Spring Data JDBC ou bien R2DBC (pour le reactive) qui permet de s'affranchir une partie des requêtes à créer
      3  0

  17. #17
    Futur Membre du Club
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2019
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2019
    Messages : 1
    Points : 8
    Points
    8
    Par défaut
    La réponse n'est pas binaire.

    L'ORM est portable entre SGBD (apres est ce que l'on change souvent de SGBD ?), simplifie grandement la maintenance et les accès. En gros, il faut pour vous le travail d'accès à la base.

    MAIS, ce n'est pas performant: surcharge et pas de possiblité d'utiliser toutes les fonctionnalités du SQL (par exemple: le insert or update de mysql avec linq).

    Le SQL directement est clairement plus performance mais c'est la maintenance qui est beaucoup plus compliquée et le code appelant que l'on doit ecrire pour chaque requete.

    J'ai eu plusieurs cas avec des sites internet. On gagne quelques ms en SQL direct (multiplié par le nombre de requete, c'est enorme). Et en SEO, le temps de reponse est important.
    Le gain est aussi important quand on doit gérer beaucoup de donnée.

    Apres, j'ai vu aussi un problème developpeur: l'orm simplifie l'acces du coup, le dev ne prend plus la peine de recuperer juste ce qu'il a besoin. On recupere toutes les données de la row alors que l'on a besoin qu'une date par exemple.

    La librairie dapper a fait des tests de perfo: https://github.com/StackExchange/Dapper pour ceux que cela interresse. On voit clairement que le SQL direct est gagnant en perf.

    En résumé, pour des petites projets ne demandant pas des reponses en quelques ms, utilisé l'ORM sinon utiliser SQL directement (au moins en partie).

    Sinon, je suis tombé récement sur un projet intermédiaire: sqlwrapper (C#). Cela genere du code à partir de la requete SQL automatiquement.
    En gros, vous écrivez votre requete dans un fichier text et automatiquement il genere le code C# appelant avec les paramètres. Apres test, cela marchotte mais c'est prometteur car cela simplifirait grandement l'utilisation du SQL directement.
      5  0

  18. #18
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par marc.collin Voir le message
    Je suis partout de 0 il y a environ 5 ans niveau orm et je trouve que le gain n'est pas si énorme en terme d'économie de temps.
    Si tu ne trouves pas que le gain de temps est conséquent, c'est probablement que ton code derrière n'est pas bien factorisé.

    Personnellement dans doctrine je travaille avec des minis fonctions dans les repository qui servent à constituer les requêtes de manière chaîanable.

    Ainsi si j'ai besoin de récurer mes produits par ordre alphabétique je fais : $products = $repo->initQuery->getProducts()->sortByName()->fetchAll();
    Si ailleurs j'ai besoin d'un seul produit : $product = $repo->initQuery()->getProducts()->byId(10)->fetch();
    Et je peux imaginer d'avoir besoin d'uniquement de ceux appartenant à au moins 3 catégories, puis les trier par nombre de catégories tiens : $repo->initQuery->getProducts()->whereHasCatgoriesCount(3)->sortByCategoriesCount()->fetchAll();

    C'est clair, concis, réutilisable partout, on y greffe très facilement autant de choses que l'on veut et autant de variantes que nécessaires sans encombrer le controller de code inutile.
      2  8

  19. #19
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    729
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 729
    Points : 1 414
    Points
    1 414
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Si tu ne trouves pas que le gain de temps est conséquent, c'est probablement que ton code derrière n'est pas bien factorisé.
    On en revient à la méthode : si les bases ne sont pas là .. les technos qui permettent d'aller plus vite nous poussent dans le mur avec d'autant plus de force.

    Investir du temps sur un ORM, sur du SQL, sur une méthode, ... c'est toujours y passer du temps ; temps non directement productif.
    Faut aller plus vite.

    Si l'objectif est d'étaler de la peinture au mur, arrose le à coup de seau de peinture = objectif atteint.
    Le savoir est une nourriture qui exige des efforts.
      7  2

  20. #20
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 851
    Points : 2 424
    Points
    2 424
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Si tu ne trouves pas que le gain de temps est conséquent, c'est probablement que ton code derrière n'est pas bien factorisé.
    il est question ici de valider ce que le orm génère comme requête et non de factorisation.

    Citation Envoyé par Sodium Voir le message
    Personnellement dans doctrine je travaille avec des minis fonctions dans les repository qui servent à constituer les requêtes de manière chaîanable.

    Ainsi si j'ai besoin de récurer mes produits par ordre alphabétique je fais : $products = $repo->initQuery->getProducts()->sortByName()->fetchAll();
    Si ailleurs j'ai besoin d'un seul produit : $product = $repo->initQuery()->getProducts()->byId(10)->fetch();
    Et je peux imaginer d'avoir besoin d'uniquement de ceux appartenant à au moins 3 catégories, puis les trier par nombre de catégories tiens : $repo->initQuery->getProducts()->whereHasCatgoriesCount(3)->sortByCategoriesCount()->fetchAll();

    C'est clair, concis, réutilisable partout, on y greffe très facilement autant de choses que l'on veut et autant de variantes que nécessaires sans encombrer le controller de code inutile.
    Pas besoin d'un orm pour faire ça... spring-data en est la preuve
      1  0

Discussions similaires

  1. Réponses: 8
    Dernier message: 05/07/2021, 10h47
  2. Réponses: 98
    Dernier message: 30/04/2017, 23h12
  3. Réponses: 5
    Dernier message: 22/03/2006, 15h54
  4. Réponses: 5
    Dernier message: 20/10/2005, 11h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo