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

Version imprimable

Voir 40 message(s) de cette discussion en une page

21/05/2019, 13h20
marc.collin

Citation:

Envoyé par soazig

Bonjour,
Personnellement, sur mon dernier projet j'utilise le meilleur des deux mondes, ORM (entity framework) en lecture et procédures stockées en écriture. Dans ce cas précis, il s'agit d'une réécriture d'application existante dans une autre techno, les procédures stockées existaient déjà, et leur logique était compliquée (écriture dans 5 tables avec recalcul récursif), je les ai juste nettoyé un peu.

Par ailleurs j'ai constaté que lorsqu'une requête entity framework devenait un peu trop compliqué (par exemple lecture d'une vingtaine de colonnes dont une dizaine calculées, en provenance d'une dizaine de tables, à un certain moment entity framework n'y arrivait plus.La requête part en erreur dés qu'on rajoute une colonne. De plus le rajout de la dite colonne, rajoute un left outer join UneTable alors que la table en question était déjà en left outer join. Dans ces cas là j'ai utilisé une vue avec des jointures sur les tables de bases. Au final :un résultat plus rapide.

Je sais que les dev puristes vont m'attaquer en me disant que la logique de l'application n'est plus uniquement dans le code c#, mais j'assume.
Bonne journée
Soazig

je dirais pas trop le choix quand tu veux de la performance de contourner les lacunes des orm...
21/05/2019, 13h24
Sodium

Citation:

Envoyé par SQLpro

Nous en revenons donc au point clef : problème de formation !

Le SQL permettant de factoriser le code de la même manière que le ferais un développeur avec des méthodes et les espaces de noms. Ceci se fait par le biais des schémas SQL, des vues, des UDF table et des CTE. Je ne voit aucun autre problème que la méconnaissance totale et profonde de ces concepts, par la très grande majorité des développeurs prétendant connaître les bases de données relationnelles.

Et quand je voit des soit disant prof d'informatique enseigner les SGBDR avec MySQmerde qui ne sait que peut ou pas implémenter ces concepts, on continue à fabriquer des crétins !
https://www.amazon.fr/dp/2350130355

A +

Ahhhh élitisme prétentieux quand tu nous tiens ;)
21/05/2019, 13h27
marc.collin

Citation:

Envoyé par SQLpro

Nous en revenons donc au point clef : problème de formation !

Le SQL permettant de factoriser le code de la même manière que le ferais un développeur avec des méthodes et les espaces de noms. Ceci se fait par le biais des schémas SQL, des vues, des UDF table et des CTE. Je ne voit aucun autre problème que la méconnaissance totale et profonde de ces concepts, par la très grande majorité des développeurs prétendant connaître les bases de données relationnelles.

Et quand je voit des soit disant prof d'informatique enseigner les SGBDR avec MySQmerde qui ne sait que peut ou pas implémenter ces concepts, on continue à fabriquer des crétins !
https://www.amazon.fr/dp/2350130355

A +

toujours obligé de dénigrer?

tu enseignerais plutôt avec microsoft sql server?
21/05/2019, 13h51
deltree

Citation:

Envoyé par SQLpro

Histoire de mettre de l'huile sur le feu…
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

Ecrit il y a 14 ans et visiblement toujours d'actualité !

A +

Non désolé, c'est un peu daté quand même, avec tous les clichés sur les ORM: je cite "Bonne idée, mais mauvaise pioche…"
Des raccourcis un peu rapides, je cite: "d’Hibernate à iBatis en passant par l’inabouti Entity Framework,"
iBatis (et myBatis) permett justement d'écrire librement son SQL, ce n'est presque plus un ORM!

Et d'autres qui ne sont plus d'actualité, je cite aussi : "Quant à la qualité des requêtes SQL les connaisseurs apprécieront : du fait qu'il faut être compatible avec tout un tas de SGBDR, le nivellement se fait par le bas.": Faux et archifaux, ils y a des notions de "dialectes" définis séparément pour chaque base de données, donc les requetes sont bien optimisée pour le moteur SQL

Je suis plutot pro-ORM, et comme je l'ai dis, j'entends les arguments contre, mais ceux qui sont valides, allez je me fait l'avocat du diable:
- requetes "n+1": arrivent trop souvent lorsqu'un développeur ne maitrise pas les jointure eager/lazy
- requetes SQL complexes difficiles à transposer en JPQL

ce à quoi je m'empresse d'ajouter le contre-argument:
- 1. il faut maitriser le eager Lazy, oui, et vérifier ses Requetes SQL générées, voire les monitorer
- 2. Ecrivez des requetes natives! l'orm ne l'empeche pas, et posez vous la question de la nécessité de cette requete (problème de modélisation?)

mais c'est bien, ce document permet justement de comprendre les clichés du langage populaire du type "Java c'est lent"
21/05/2019, 14h32
Sodium

Il faudrait un jour que les prétendus experts sortent de leur bulle et se rendent compte que tout le monde n'a pas les mêmes besoins.
Dans une majorité de projets, mettre toute la logique côté bdd serait totalement contre-productif car cela veut dire que l'entreprise devra former tout son personnel à ces manipulations et il sera moins facile d'embaucher de nouvelles personnes.
Dans le cas d'un webshop ou d'un site de contenu, on attaque généralement une vingtaine de tables maximum et l'ORM est parfaitement adapté à cela. Les requêtes étant généralement simples, la performance n'est même pas un sujet.
Il est également parfaitement logique de garder toute la logique de l'application en un seul endroit. Je serais également curieux de savoir comment se gère le versionning d'une application gérée côté bdd avec les outils les plus utilisés par les développeurs tels que git.
21/05/2019, 14h45
al1_24

Citation:

Envoyé par Sodium

Je serais également curieux de savoir comment se gère le versionning d'une application gérée côté bdd avec les outils les plus utilisés par les développeurs tels que git.

De la même manière qu'avec les autres langages :roll:
Les programmmes source contiennent le DDL des objets de la base (schémas, tables, vues, procédures, packages...). Ils sont exécutés au moment du déploiement.
Il suffit juste de s'assurer que l'ordre de création des objets tient bien compte de leurs dépendances.
21/05/2019, 16h44
MaitrePylos

Citation:

Envoyé par Sodium

Il faudrait un jour que les prétendus experts sortent de leur bulle et se rendent compte que tout le monde n'a pas les mêmes besoins.

C'est ce qu'on vous dit depuis longtemps, mais vous avancez des arguments qui sont contre productifs.
C'est vous qui avez lancé le

Citation:

Envoyé par Sodium

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.

Ce qui n'a aucun sens et à côté de la plaque.
Vous êtes dev et avez besoin d'un entrepôt de données et vous vous moquez de comment c'est fait (comme une grosse partie des dev en fait) et bien un ORM est parfait pour ça, c'est le dev de l'ORM en question qui choisira pour vous.
Vous devez utiliser massivement une DB, les DBA sont pour là.
J'enseigne la programmation et du coup, on utilise un ORM.
Mon boulot, c'est de migrer des données (ETL) et du coup, j'utilise massivement le SQL.
21/05/2019, 17h28
SQLpro

Citation:

Envoyé par marc.collin

toujours obligé de dénigrer?

tu enseignerais plutôt avec microsoft sql server?

J'ai enseigné avec Oracle, IBM DB2, SQL Server et PostgreSQL….

A +
21/05/2019, 17h36
Sodium

Citation:

Envoyé par MaitrePylos

Ce qui n'a aucun sens et à côté de la plaque.
Vous êtes dev et avez besoin d'un entrepôt de données et vous vous moquez de comment c'est fait (comme une grosse partie des dev en fait) et bien un ORM est parfait pour ça, c'est le dev de l'ORM en question qui choisira pour vous.
Vous devez utiliser massivement une DB, les DBA sont pour là.
J'enseigne la programmation et du coup, on utilise un ORM.
Mon boulot, c'est de migrer des données (ETL) et du coup, j'utilise massivement le SQL.

Ah mais je n'ai jamais dit que les ORM étaient une solution parfaite loin de là. Ils sont un sparadrap posé parce que les développeurs en ont eu assez d'attendre que le standard évolue, un peu comme les 200 surcouches que l'on rajoute systématiquement sur JavaScript (parfois carrément un nouveau langage). Et forcément, un sparadrap, ça a des faiblesses et c'est un peu moche, mais dans la majorité des cas c'est toujours mieux qu'une plaie ouverte.
21/05/2019, 18h59
marc.collin

Citation:

Envoyé par SQLpro

Histoire de mettre de l'huile sur le feu…
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

Ecrit il y a 14 ans et visiblement toujours d'actualité !

A +

énormément de raccourcie....

en mettre plus dans la bd ne fait qu'augmenter la liaison du système à une base de donnée et donc un produit, être à la merci de l'éditeur, des coûts de licence, des versions et de leur fin de vie...

avec l'explosion des systèmes distribués qui en font de moins en moins, ce moins est plus qu'en perte de vitesse
21/05/2019, 19h39
Pyramidev

Citation:

Envoyé par SQLpro

Nous en revenons donc au point clef : problème de formation !

Le SQL permettant de factoriser le code de la même manière que le ferais un développeur avec des méthodes et les espaces de noms. Ceci se fait par le biais des schémas SQL, des vues, des UDF table et des CTE. Je ne voit aucun autre problème que la méconnaissance totale et profonde de ces concepts, par la très grande majorité des développeurs prétendant connaître les bases de données relationnelles.

D'ailleurs, pour ma culture générale, à propos des UDF (User Defined Functions), est-ce que SQL supporte la notion de fonction de première classe ? Par exemple, est-ce qu'une UDF peut elle-même prendre une UDF en paramètre et retourner une UDF ? Si oui, est-ce qu'une fonction peut avoir un état qui dépend du runtime, ou bien est-ce que les fonctions sont toujours sans état, comme les pointeurs de fonction en C ?
S'il n'y a pas de fonctions de première classe, y a-t-il quelque chose qui s'en rapproche, comme les fonctions virtuelles de la programmation orientée objet ?
Si oui, aurais-tu un exemple de bout de code pour illustrer cela ? Existe-il un SGDB gratuit qui supporte ce genre de chose, ou bien est-ce limité à des SGDB payants ?

Vu de loin, pour maintenir du code métier, quand les besoins en performances ne sont pas exigeants, SQL semble très limité comparé aux langages les plus souvent utilisés par les développeurs. Mais je préfère poser la question pour vérifier.
21/05/2019, 20h49
Michel.Priori

Citation:

Envoyé par Pyramidev

SQL semble très limité comparé aux langages les plus souvent utilisés par les développeurs.

Et pour cause : le SQL est un langage de 4ieme génération.
Les langages dont vous faites la description sont de 3ieme.
Plus on augmente le niveau d'abstraction, moins les possibles sont étendus.
Prenez par exemple le binaire, pouvez vous faire autant d'actions avec votre langage favori qu'en binaire ?

J'espère que votre réponse est une réponse d'agacement.
Si vous voulez définitivement vous convaincre de la limite du SQL essayez de faire que le résultat d'un requête renvoie une ligne sur 2 en gras dans un cadre rouge.

Saviez vous que les boucles et les variables n'existent pas en SQL ?

Si ceci vous avez échappé, je rejoint SQLpro pour dire qu'il y a une profonde méconnaissance de ce qu'est le SQL.
21/05/2019, 20h58
Sodium

Donc votre réponse en gros c'est "SQL c'est limité mais c'est trop bien et ceux qui pensent le contraire sont des ignorants et on ferait mieux de tous coder en binaire (allez disons en assembleur pour être gentils)" ?
21/05/2019, 22h18
Pyramidev

Citation:

Envoyé par Michel.Priori

Saviez vous que les boucles et les variables n'existent pas en SQL ?

Ça existe en Transact-SQL et en PL/SQL.
22/05/2019, 02h32
MaximeCh

Il y a une règle d'or qui dit que les fonctions ne doivent pas avoir d'effet de bord, ne doivent pas écrire en tables. C'est réservé aux procédures stockées.
22/05/2019, 07h10
Michel.Priori

Citation:

Envoyé par Sodium

Donc votre réponse en gros c'est "SQL c'est limité mais c'est trop bien et ceux qui pensent le contraire sont des ignorants et on ferait mieux de tous coder en binaire" ?

Mon dieux que vous êtes obtus.
Je ne comprenais pas les réponses virulentes à votre endroit, je commence à comprendre.
J'espère que vous n'encadrez personne et, si vous adoptez cette attitude avec vos enfants, j'espère pour vous qu'ils auront qu QI plus élevé que le votre ; ils vont vous faire évoluer.

En vrai je ne sais pas comment vous répondre pour essayer de garder l'esprit du forum : de l'entraide.
Qu'attendez-vous comme entraide en postant ici ?
Si vous pensez contribuer, en quoi vos posts sont utiles ?

Je vous laisse à vos réflexions.
Pour ma part, je ne prendrais plus la peine de vous répondre à aucun de vos posts.
22/05/2019, 07h15
Michel.Priori

Citation:

Envoyé par Pyramidev

Ça existe en Transact-SQLet enPL/SQL.

Oui.
Et en JAVA et en .NET qui, respectivement, sont des langages acceptés chez OracleDB et SQL server, pour faire des fonctions et des procédures.

Mais je me demande ce que ceci apporte au débat : " Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ?" :weird:

J'ai du perdre le fil à un moment.
22/05/2019, 07h51
Pyramidev

Citation:

Envoyé par Michel.Priori

Oui.
Et en JAVA et en .NET qui, respectivement, sont des langages acceptés chez OracleDB et SQL server, pour faire des fonctions et des procédures.

Aucun rapport. Regarde les liens Wikipédia que j'ai donnés pour Transact-SQL et PL/SQL. Il y a des exemples de code avec des variables et des boucles.
Par exemple, pour PL/SQL, il ne s'agit pas d'appeler du Java depuis PL/SQL, mais d'utiliser des variables et des boucles directement en PL/SQL.

Citation:

Envoyé par Michel.Priori

J'ai du perdre le fil à un moment.

À un moment, Frédéric Brouard (alis SQLpro) a donné un lien vers un PDF qu'il a écrit il y a 14 ans :

Citation:

Envoyé par SQLpro

Histoire de mettre de l'huile sur le feu…
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

Ecrit il y a 14 ans et visiblement toujours d'actualité !

Le PDF en question ne parle pas seulement des ORM. Il traite aussi la question : Où placer le code métier ? Dans la base de données ou bien ailleurs ?
Dans le PDF en question, l'auteur croit que, en écrivant le code métier directement dans la base de données, on divise le temps global de développement par 2 ou 3 en plus d'augmenter les performances et que, la seule raison pour laquelle les développeurs préfèrent écrire le code métier en dehors, c'est parce qu'ils connaissent mal les SGBDR.
22/05/2019, 09h06
SQLpro

Citation:

Envoyé par marc.collin

énormément de raccourcie....

en mettre plus dans la bd ne fait qu'augmenter la liaison du système à une base de donnée et donc un produit, être à la merci de l'éditeur, des coûts de licence, des versions et de leur fin de vie...

En mettre plus dans l'outil de développement applicatif c'est augmenter la liaison du système au langage du Framework/ORM... et donc à un produit, donc être à la merci d'un éditeur, qu'il soit libre ou commercial… donc de tous les coûts, de licence, d'évolution, de documentation….

Bref argument stupide !

Et comme les SGBDR sont beaucoup plus pérennes que les outils de dev (combien de fois avez vous changé de techno de dev en 30 ans ???? : Cobol, pascal, C++, Java, Python….) je pense qu'il y a plus à gagner qu'à perdre en portant le max de chose dans le SGBDR plutôt que dans l'outil de dev….
La pérennité des SGBDR tient au fait qu'ils contiennent des données et de ce fait ils ont une inertie inhérente que les outils de dev n'ont pas.
En sus, les SGBDR reposent sur une théorie mathématique simple et efficace, ce que les autres n'ont pas, et quand je parle des autres, je parle aussi bien des SG BD non relationnels (le NoSQL a sans arrêt été modifié obligeant à tout recoder) comme des outils de dev et leurs langages associés.

A +
22/05/2019, 09h18
Cincinnatus

Citation:

Envoyé par Pyramidev

Aucun rapport. Regarde les liens Wikipédia que j'ai donnés pour Transact-SQL et PL/SQL. Il y a des exemples de code avec des variables et des boucles.
Par exemple, pour PL/SQL, il ne s'agit pas d'appeler du Java depuis PL/SQL, mais d'utiliser des variables et des boucles directement en PL/SQL.

Comme disait @Michel.Priori, les boucles et variables n'existent pas en SQL. Le PL/SQL (je n'ai pas utilisé Transact-SQL) est une couche en plus, à côté, de SQL pour justement réaliser les traitements procéduraux que ne permet pas SQL. Je dis bien à côté car du code PL/SQL peut exécuter du code SQL, tout comme une requête SQL peut appeler une fonction (UDF) PL/SQL.

Citation:

Envoyé par Pyramidev

À un moment, Frédéric Brouard (alis SQLpro) a donné un lien vers un PDF qu'il a écrit il y a 14 ans :

Le PDF en question ne parle pas seulement des ORM. Il traite aussi la question : Où placer le code métier ? Dans la base de données ou bien ailleurs ?
Dans le PDF en question, l'auteur croit que, en écrivant le code métier directement dans la base de données, on divise le temps global de développement par 2 ou 3 en plus d'augmenter les performances et que, la seule raison pour laquelle les développeurs préfèrent écrire le code métier en dehors, c'est parce qu'ils connaissent mal les SGBDR.

La question du temps de développement selon la technologie utilisée... un sacré marronnier.

Si on ne fait que lire et écrire des données en base, je ne pense pas que le PL/SQL soit indiqué (sauf à réaliser des API pour les ajouts/modifications de données). Par contre, il m'est arrivé de développer des applications nécessitant des calculs sur un bon volume de données pour obtenir un résultat synthétique. Il aurait été stupide de remonter toutes les données brutes dans l'application pour les y traiter et réinjecter le résultat en base pour le persister. Là, le PL/SQL était le moyen adapté. Donc l'emplacement du code métier est, comme le reste, fonction des contraintes des applications.

Voir 40 message(s) de cette discussion en une page