je dirais pas trop le choix quand tu veux de la performance de contourner les lacunes des orm...Envoyé par soazig
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
Oui
Non
Pas d'avis
Discussion :
je dirais pas trop le choix quand tu veux de la performance de contourner les lacunes des orm...
Ahhhh élitisme prétentieux quand tu nous tiens
toujours obligé de dénigrer?
tu enseignerais plutôt avec microsoft sql server?
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"
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.
De la même manière qu'avec les autres langages
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.
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.
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
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.
Il faut toujours viser la lune, car même en cas d'échec on arrive dans les étoiles. O.Wilde
Mes Articles/Critiques :
Merise - Guide pratique
PHPExcel
PostgreSQL : Administration et exploitation d'une base de données
PostgreSQL : Entraînez-vous à créer et programmer une base de données relationnelle
J'ai enseigné avec Oracle, IBM DB2, SQL Server et PostgreSQL….
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
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.
é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
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.
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.
Le savoir est une nourriture qui exige des efforts.
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)" ?
Ça existe en Transact-SQL et en PL/SQL.
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.
Empreinte PGP - Je suis les règles de Crocker.
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.
Le savoir est une nourriture qui exige des efforts.
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 ?"
J'ai du perdre le fil à un moment.
Le savoir est une nourriture qui exige des efforts.
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.
À 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.
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 +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
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.
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager