Oui donc tu n'as toujours rien à dire. Hop, ignore listEnvoyé par blbird
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 :
Oui donc tu n'as toujours rien à dire. Hop, ignore list
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 ?
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.
Le savoir est une nourriture qui exige des efforts.
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.
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.
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 :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.
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
Bon deja, je vois pas la rapport avec l'etat de fait que les lib js c'est le bordel.
Pour reprendre tes mots :
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
@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.
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".
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 ?
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).
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.
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
Le savoir est une nourriture qui exige des efforts.
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 +
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/ * * * * *
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
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 +
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/ * * * * *
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