Oui donc tu n'as toujours rien à dire. Hop, ignore list ;)Citation:
Envoyé par blbird
Version imprimable
Oui donc tu n'as toujours rien à dire. Hop, ignore list ;)Citation:
Envoyé par blbird
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
Est-ce pour vous un problème inhérent à l'usage d'un ORM ou est-ce une faiblesse de celui-ci en particulier ?Citation:
Envoyé par soazig
Ps : la solution à base de vue et de PS est l'archi que je préconise le plus souvent. Elle a ses défauts . Mais, somme toutes, elle reste un bon compromis dans nombre d'architecture.
Rebonjour
C'est une faiblesse d'entity framework 5, je ne sais pas si c'est valable pour les autres ORM. Je ne connais que Nhibernate et Entity Framework, et je n'ai pas eu à pousser NHibernate dans ces retranchements.Citation:
Envoyé par Michel.Priori
a+
Soazig
@Michel.Priori Pour repondre a tes objections :
Ligne 2) C'est pas parce qu'une appli A est en sql pur que la B qui utilise la meme base de donnees devrai etre en sql pur aussi.
Objection : L'évolution de la base va être un point d'achoppement.
Même 2 projets objets qui pointeraient la même base (parce que) mais ne partageant pas le même modèle objet est un merdier sans nom. Alors de là à imaginer un projet avec un ORM et d'autres sans ... bonjour les dégâts.
N'oublions pas qu'un ORM utilise certes mais aussi implémente les éléments de la base en fonction du modèle présenté.
Donc si on parle de vrais orm (entity ou hibernate) tu as plusieurs modes de fonctionnements dont a chaque fois "db first". Si tu es en db first le model object est genere a partir de ce qui a ete defini en db. Partant de la si tu requete la bdd via des procedures sotckees ou via l'orm cote bdd il n'y a aucuns imapcts notables.
Ligne 3) Niveau completement debutants un orm est plus simple a prendre en main.
Objection : ce que je ne connais pas m'est difficile.
Il parait que le français est très complexe ; c'est un chinois qui me l'a dit
C'est ton point de vue, et le mien est different, donc subjectif d'un cote et de l'autre, lequel a raison, lequel a tord : aucuns.
Ligne 5) Si on veut devenir dba oui, sinon non.
Objection : cet argument à été soulevé quelques posts plus tôt : Le langage SQL évolue mais reste stable dans le temps malgré les dialectes. Les ORM, du fait de la compétition, sont plus nombreux et leur durée de vie moyenne est donc plus courte.
en c# ou en java il y a que 2 orm reellements sur le marche, je ne connais pas le monde js ou le monde php. Si demain un profil confirme c# vient me voir et me dit qu'il a jamais fait de entity framework je rigole.
Ligne 6) Idem c'est pour les dba.
Objection : Les ORM sont limités dans leur proposition aux techniques qui ont des "équivalences" chez les autres. Tout sujet pour lequel un SGBD à une "longueur" d'avance (ou expertise ou bibliothèque ou ... ce qu'on veux, vous m'avez compris) est forcément moins bien exploité par un ORM
Tout a fait un orm ne saura jamais aussi bien creer les index necessaires qu'un dba, ni denormaliser une table pour un gaind e perf. Mais ce n'est pas le boulot d'un dev mais celui d'un dba.
le gros soucis qu j'ai avec tous ce qui est cote db c'est sur le travail en equipe et le deploiement. Une base de donnees n'est pas versionnee, et partir a l'aventure a chque deploiement pour decouvrir ce que les devs ont change coute un temps enorme.
Meme combat si devs veulent modifier la meme vues/table/procedure stockee et je ne parle pas du cout de debug de pl/sql.
Partant de la je prefere dans la majorite des cas un orm qui facilitera grandement le travail en equipe et les deploiements.
En PHP tu as globalement deux frameworks majeurs, Symfony qui utilise l'ORM Doctrine et Laravel (qui se fait de plus en plus une place de choix mais reste confidentiel en France) qui utilise Eloquent.Citation:
Envoyé par mermich
Et effectivement la pertinence de la question reste discutable car de nouveaux standards il n'y en a pas tous les deux ans non plus. Ou alors on décide tous que l'on reste sur du C pour être sûrs de n'avoir aucun bouleversements.
Du coup, parmi les langages populaires, il n'y a que JavaScript qui a un écosystème instable pour les ORM ?
JavaScript est un cas particulier. Comme il s'agit d'un langage peu abouti avec énormément de faiblesses et beaucoup d’absurdités (vidéo hilarante sur le sujet ici : https://www.destroyallsoftware.com/talks/wat), il existe des milliers de librairies pour combler ses lacunes ou l'étendre dans une anarchie totale. Dans ces conditions, difficile d'avoir un ou deux standards qui s'imposent.
La version un peu plus juste :Citation:
Du coup, parmi les langages populaires, il n'y a que JavaScript qui a un écosystème instable pour les ORM ?
Du coup, parmi les langages populaires, il n'y a que JavaScript qui a un écosystème instable.
Tu dis ça parce que tu n'y connais rien et que tu es incompétent, d'ailleurs déclarer des fonctions dans des fonctions avec 35 callbacks imbriqués c'est le summum de l'élégance en programmation et tous ceux qui pensent le contraire sont des abrutis.
Si tu fais référence aux codes dégueulasses qui utilisent le continuation-passing style (surnommé callback hell) pour gérer l'asynchronisme, il s'agit du vieux JavaScript. Ensuite, il y a eu les promesse. Et après, il y a eu les mot-clefs async et await qui ont permis d'arrêter de massacrer la lisibilité du code pour gérer l'asynchronisme.Citation:
Envoyé par Sodium
Voir l'article : Asynchronous JavaScript: From Callback Hell to Async and Await
Je connais, mais ce n'est pas parce que JS devient peu à peu moins pire au fil du temps qu'il faut arrêter de s'en moquer :mrgreen:
Bon deja, je vois pas la rapport avec l'etat de fait que les lib js c'est le bordel.Citation:
Envoyé par Sodium
Pour reprendre tes mots :
;)Citation:
Pour le reste, je n'ai pas envie de répondre à des insultes. De toute manière, quand on en vient aux insultes c'est généralement que l'on n'a pas grand-chose de pertinent à dire.
Euh ça me paraissait tout de même assez évident que c'était de l'ironie over 9000 et un clin d'oeil à notre ami blbird :aie:
@mermich : Le message « Tu dis ça parce que tu n'y connais rien et que tu es incompétent » de Sodium était du second degré. Il caricaturait des messages de développeurs qui défendaient JavaScript.
Edit : Sodium a répondu en même temps que moi.
@mermich : J'apprécie beaucoup que vous preniez la peine d'argumenter tout en élevant le débat.
Merci.
Ce qui ne veux pas dire que je soit d'accord pour autant. ;)
Allons y :
[/QUOTE]
La définition/qualification de l'ORM n'étant pas posé, il faut prendre le débat en termes génériques.Citation:
Envoyé par mermich
Donc soit le mode "db first" est un standard respecté, soit on est obligé de ne pas en parler ici.
Ceci dit, peu importe : imaginons un ERP dont le modèle objet de l'éditeur n'est ni connu ni disponible. Cet ERP est "amélioré" par 2 ou 3 sociétés qui "adaptent" le progiciel.
Le code SQL étant stocké dans différents codes, comment mesurer l'impact d'une modification de structure ? Comment ne pas prendre le risque de faire planter les autres codes dont on n'a pas accès au source et qui restent en développement ?
Non.
Dans ce cas de figure il faut partager le modèle objet, ou, centraliser le code coté SQL pour pouvoir gérer les dépendances.
Je valide cette conclusion, et c'est bien pour ça que je l'ai placé en "équivalent".Citation:
Envoyé par mermich
L'image de la langue français/chinois n'est pas anodine : on remarque qu'il faut environ 2 ans à un bébé pour apprendre la langue parlée respectivement.
Par contre l'apprentissage de la langue écrite n'est pas le même en terme de temps d’acquisition.
Pour l'utilisation d'un ORM (qui pré-suppose l'acquisition du langage objet de référence) je serais plutôt enclin à dire que c'est globalement plus long à apprendre que le SQL. Mais les possibles n'étant pas les mêmes, entre le langage objet et le SQL, on en compare pas la même chose.
Restons à l'équité.
Justement, la "portabilité" de votre compétence "entity framework", en dehors du c#, est-ce l'équivalent d'un "dialecte SQL" ou est-ce plus lourd ?Citation:
Envoyé par mermich
Pour me faire changer d'avis il faudrait que la "puissance" du standard ORM soit plus restrictif que celle de la norme SQL.
La question de savoir qui a la responsabilité de créer les index est en soit un sujet. C'est en partant de ce constat que M$ à créé le rôle de DBO, ni développeur ni DBA (SysAdmin pour le coup).Citation:
Envoyé par mermich
Oublions cet aspect si vous le voulez bien.
Plus la requête est complexe plus il existe de façon de l'écrire. Normalement le moteur d'optimisation du serveur devrait trouver le plan optimal quel que soit la formalisation de la requête. C'est un idéal ... non atteint.
En fait il n'est pas rare de voir que les plans sont effectivement différents en fonction de l'écriture, de la version du serveur et de la volumétrie existante (plus exactement de la pertinence des statistiques). C'est là que se trouve la justification de l'infamie : les hints.
Donc non, trouver la meilleure écriture d'une requête n'est pas du rôle du DBA et un ORM n'a pas la latitude nécessaire pour explorer toutes les variations offertes par un "dialecte" SQL particulier.
Ceci est une critique structurelle inhérente à la complexité à la quelle un ORM tente de faire face.
Ce n'est pas une critique d'un ORM particulier.
Je pense, sincèrement, que c'est un problème d'adressage de la complexité.
Oui, je suis d'accord.Citation:
Envoyé par mermich
Je ne sais pas comment le formaliser simplement pour ne pas entrer en contradiction avec le point 2.
Peut être : "gestion du versioning et du déploiement" ?
Si vous adhérez, ajoutez vous même la ligne 7 ;)
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 +
C'est à côté de la plaque sur beaucoup de points.
reste queles développeurs sont peu habitués à passer trois jours à élaborer une requête alors que rien neles gênent à développer pendant trois semaines la même procédure client qui fera le mêmetraitement, mais de manière itérative, c'est à dire mille fois moins performante
Huhu bon courage pour debugger et modifier une requête écrire en trois jours. Je réitère la citation précédente : d'abord on code pour l'humain, ensuite pour la machine, ensuite si besoin on optimise.
Bon après c'est sûr, ça garantit la sécurité de l'emploi pour la seule personne de la boîte qui comprend concrètement ce qu'il a écrit...
Passionnant, je valide en tout point :plusser: :)Citation:
Envoyé par SQLpro
Citation:
Envoyé par Sodium
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 +
je dirais pas trop le choix quand tu veux de la performance de contourner les lacunes des orm...Citation:
Envoyé par soazig
Ahhhh élitisme prétentieux quand tu nous tiens ;)Citation:
Envoyé par SQLpro
toujours obligé de dénigrer?Citation:
Envoyé par SQLpro
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…"Citation:
Envoyé par SQLpro
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 :roll:Citation:
Envoyé par Sodium
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.
C'est ce qu'on vous dit depuis longtemps, mais vous avancez des arguments qui sont contre productifs.Citation:
Envoyé par Sodium
C'est vous qui avez lancé le
Ce qui n'a aucun sens et à côté de la plaque.Citation:
Envoyé par Sodium
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.
J'ai enseigné avec Oracle, IBM DB2, SQL Server et PostgreSQL….Citation:
Envoyé par marc.collin
A +
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.Citation:
Envoyé par MaitrePylos
énormément de raccourcie....Citation:
Envoyé par SQLpro
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 ?Citation:
Envoyé par SQLpro
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.Citation:
Envoyé par Pyramidev
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.
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.Citation:
Envoyé par Michel.Priori
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.
Mon dieux que vous êtes obtus.Citation:
Envoyé par Sodium
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.
Oui.Citation:
Envoyé par Pyramidev
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.
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.Citation:
Envoyé par Michel.Priori
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 :Citation:
Envoyé par Michel.Priori
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 ?Citation:
Envoyé par SQLpro
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….Citation:
Envoyé par marc.collin
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 +
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
La question du temps de développement selon la technologie utilisée... un sacré marronnier.Citation:
Envoyé par Pyramidev
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.