Linq to sql : Avis

Je pense qu'il faut éviter de faire un amalgame : ce n'est pas parce qu'on utilise un ORM que ça sera nécessairement moins propre ou moins performant ou moins robuste.

Forcément, c'est plus facile pour un âne de faire des requêtes en Linq to Entities qu'en SQL directement ou avec une procédure stockée, car l'ORM facilite ce travail de part la lecture/écriture plus "fonctionnelle" (terme à prendre avec des pincettes)

Pour autant, quand on sait ce qu'on fait, généralement on le fait bien, et on est plus prudent là dessus. Personnellement, je vérifie toujours les performances du code généré via SQL Profiler notamment.

En prenant également un peu de hauteur, il faut aussi prendre en compte le fait que stratégiquement, les développeurs de demain n'auront peut-être plus vocation à savoir faire du SQL - d'autant qu'ils seront de moins en moins des "occidentaux" - ce sera le rôle des seuls DBA, qui feront d'ailleurs peut-être surement de plus en plus de conseil au niveau des ORM.

En résumé, je pense qu'il ne faut pas jeter la pierre sur les ORM, mais plutôt participer à leur bonne utilisation par les développeurs, qui ne doivent pas hésiter à ce tourner vers les DBA.

Citation:

---

Envoyé par iberserk

Daccord... sujet maintes fois débattu sur DEV.COM....

L'idéal: de bons développeurs avec de bons DBA...
L'ORM est un plus certains pour la productivité et peu amener de très bon résultats également même si la perte est ineluctable (si c'est bien fait ce n'est pas énorme) et ne sera pas sensible sur 90 % des appli des gestions...

---

C'est l'idéal, sauf que la publicité fait parfois l'inverse.
Bien vu comme j'adore vraiment te lire sur ce forum.

L'inverse : de bons DBA avec de bons développeurs ? ;)

Citation:

---

Envoyé par Er3van

Je pense qu'il faut éviter de faire un amalgame : ce n'est pas parce qu'on utilise un ORM que ça sera nécessairement moins propre ou moins performant ou moins robuste.

---

Justement, c'est là mon problème bien que le gain ne soit pas visible à l'échelle de seconde forcement, vous devez admettre le fait qu'il y'a au niveau des ORM tout le travail de génération du code SQL, Le Parsing ....Et ce à chaque appel de la méthode ce temps avec le code SQL, vous le gagnez même à performance égale. Et ca doit être médiatisé, car je me souviens quand j'ai débuté avec la programmation, j'ai vu des milliers de tutos sur le net sur la possibilité de création des fenêtres via glisser/déplacer sans une seule ligne de code, mais j'ai vite été pris au piège et ce n'est que ce piège que je veux éviter aux nouveaux, donc notre avenir.

Citation:

---

Envoyé par Er3van

En résumé, je pense qu'il ne faut pas jeter la pierre sur les ORM, mais plutôt participer à leur bonne utilisation par les développeurs, qui ne doivent pas hésiter à ce tourner vers les DBA.

---

Ca c'est un point par contre pour lequel je suis d'accord avec vous.

Citation:

---

Envoyé par Er3van

L'inverse : de bons DBA avec de bons développeurs ? ;)

---

Non, plutôt le fait qu'on fait passer les nouveaux outils pour des remplaçons des anciens avec un tableau de publicité très allechant et désolé si tu tombes dans ce charme, ce qui est rarement évitable pour un nouveau.

Citation:

---

Envoyé par WOLO Laurent

Justement, c'est là mon problème bien que le gain ne soit pas visible à l'échelle de seconde forcement, vous devez admettre le fait qu'il y'a au niveau des ORM tout le travail de génération du code SQL, Le Parsing ....Et ce à chaque appel de la méthode ce temps avec le code SQL, vous le gagnez même à performance égale.

---

Je suis d'accord avec ça, mais je pense qu'on ne juge pas avec la même granularité :

Si une requête s’exécute en 850 ms avec une procédure stockée, et en 925 ms avec Linq to Entities : pour moi les performances sont similaires. Evidemment, c'est un peu faux, mais je suis plus dans la perspective où c'est une perte raisonnable et acceptable pour la majorité des applications informatiques en Systèmes d'Informations.
D'autant que pour obtenir 850 ms, j'aurai besoin d'une ressource onéreuse (un DBA par exemple) et qui mettra plus de temps à faire cette requête qu'un développeur en mettra via Linq to Entities.

Après c'est une perspective discutable j'en conviens !

Vue sous cet angle, je pense que nous sommes ensembles.

Citation:

---

je vérifie toujours les performances du code généré via SQL Profiler notamment

---

Et hop un petit bisous :ccool:

Mes deux dernières boites, les deux directeurs techniques ne connaissaient même pas l'existence de cet outil indispensable aux développeurs...

Au dela du parsing, ce que je trouve dommage sur les requêtes LINQ TO SQL générées c'est leur côté très verbeux...(dû essentiellement a l'utilisation d'alias de tables extremement long et ce de manière systematique même avec une seule table.).
C'est bête mais c'est autant d'octets qui passent inlassablement sur le réseau pour rien...
Evidemment çà peut paraitre trivial mais comme le dit si bien elsuket on passe notre temps a chasser les derniers pouillemes (pluriel du bien connu pouilleme:))... et un pouilleme plus un pouilleme etc.

Citation:

---

Envoyé par Iberserk

C'est bête mais c'est autant d'octets qui passent inlassablement sur le réseau pour rien...
Evidemment çà peut paraitre trivial mais comme le dit si bien elsuket on passe notre temps a chasser les derniers pouillemes (pluriel du bien connu pouilleme)... et un pouilleme plus un pouilleme etc.

---

Ce qui nous ramène encore vers une vielle discussion

Citation:

---

Code SQL depuis le client versus Procedure stockée

---

et là nous allons voir que d'autres avantages apparaîtront (Sécurité, réutilisation du plan d'execution, recompilation ....)

Citation:

---

là nous allons voir que d'autres avantages apparaîtront (Sécurité, réutilisation du plan d'execution, recompilation ....)

---

Bien que LINQ TO SQL génère des requêtes paramétrées via sp_executeSQL...

Citation:

---

Envoyé par iberserk

Bien que LINQ TO SQL génère des requêtes paramétrées via sp_executeSQL...

---

...et que sauf erreur de ma part, le plan d'execution d'une requête paramétrée est généralement caché par la DB

En fait, je dirais même que si un projet n'est pas basé *uniquement* sur des SP, il vaut mieux avoir un ORM bien fichu, qui va automatiquement faire des requêtes paramétrées, maintenir un cache, proposer des transactions, etc, que de faire du SQL à la main (ce qui est mal fat dans 60% des cas...)

M'enfin, si je me trompe, tirez pas, je suis pas DBA ;)

Pour mon exemple sur trois tables t1 t2, t3 avec pour relation
t1 1=>* t2 1 => * t3

il fallait loader toute l’arborescence d'un t1 avec ses sous t2 et sous t3.

La requêtes que la personne avait fait était un simple select en faisait des jointures (left outer si je me rappel bien). Le problème c'est que le T1 avait des grosses colonnes (champ texte).

De mon coté j'ai fait un simple get by id sur t1, j'ai accédé à la propriété "T2s" sur T1 qui fait du lazyloading pour loader les T2 et fait une requête custom sur les T3 (je fais un tableau d'int avec les id des T2 récupéré précédemment et je fais un where in sur le champs "T2Id" dans la t3).

Comment 3 requêtes (séquentielles) peuvent aller dans les 10 fois plus vite qu'une seul requête aussi basique ?

Dans ce cas là, le problème vient du fait que les jointure démultiplie la taille du resultset et envoie autant de fois t1 qu'il y a de t3.

En Nhibernate c'est encore plus puissant car ce type de loading peut être executé sans code (en configurant un "batch-loading dans le mapping sur T3).
Le code serait juste :

Code:

---

monObjetT1.T2s.First().T3s.First()

---

(ou tout simplement au premier accès aux objets en question).

Un bon DBA aurait surement mieux fait la requête, aucun doutes la dessus, il aurait peut être insisté sur le fait de faire 3 procs ou des multi result set, mais ça serait encore ça de plus à maintenir.

Globalement un bon DBA fait de bonne requêtes et un bon "dev orm" va faire des bonnes techniques de loading.

La différence est que :
- Déjà on a plus rarement de bon DBA que de bon developpeurs (du moins dans mon domaine)
- L'expertise du "développeur ORM" apporte plus que de de la performance, cela apporte aussi de la maintenabilité/refactoring (ne pas repasser sur 100 procstock car on a touché le schema par exemple), de la productivité (rien que créer l'appel paramétré à la proc stock prend plus de ligne que ce que j'ai écris au dessus, alors ne parlons même pas la proc en elle même) et donc un retour sur investissement bien meilleur.

Mais vous inquiétez pas je ne ferrai pas des requêtes analytique ou statistique sur 15 tables en linq.
Le truc bien avec les ORM c'est que dans les 2% des cas ou la proc stock à réellement un intérêt on peut l'utiliser ;)

Citation:

---

La requêtes que la personne avait fait était un simple select en faisait des jointures (left outer si je me rappel bien). Le problème c'est que le T1 avait des grosses colonnes (champ texte).

---

Oui la requête était mauvaise, LINQ n'inventant rien il suffit par exemple de regarder la requete que génère LINQ avec votre GetById pour voir la 'bonne requête'.

Mais cela appuis votre argumentaire qui dis qu'un bon "dev orm" prévaut dans le cas ou le SQL n'est pas maitrisé.
En clair: tester les performances au fur et a mesure des devs (sql profiler) est indispensable.

J'interviens sur un site d'ebusiness sur la partie accès aux données+ modélisation de la base.

Su les 4/5 développeurs qui sont loins d'être débutants, aucun ne sait utiliser LINQ correctement...

J'aurais du rajouter un truc avant ...

En fait une notion que j'aimerais mettre en avant c'est qu'avec un bon ORM (plus nhibernate qu'EF pour le moment) le bon "dev orm" cité avant est une personne qui va faire uniquement la configuration du modèle de données et objet.


Une fois un modèle de loading intelligent et cohérent, des développeurs junior (qui n'aurait pas pu faire une meilleur proc stock que celle présenté plus haut) peuvent facilement loader ces données "sans compétences".
Il y a un gain plus large que la simple intervention de l'expert.

De mon coté j au aussi bossé avec des personnes ayant quelques années d'experiences et qui faisait une requête "select * from" dans une prostock et par flemme d'en refaire une autre allait chercher la ligne qui les interessait coté c# ... :aie:

Apres pour moi linq ou sql sont 2 outils pas aussi simple à aborder.
L'un est objet et autocomplété, l'autre est plus enseigné à l'école mais malgres tout pour bien utiliser ces outils il faut bien comprendre les tenants et aboutissants.

Je pense que l'ORM à l'avantage de permettre de faire "plus" pour des profils moins pointu quand il y a un bon lead technique qui assure le passage entre les 2 mondes.

Citation:

---

Envoyé par Philippe Vialatte

...et que sauf erreur de ma part, le plan d'execution d'une requête paramétrée est généralement caché par la DB

---

Oui, en effet, mais ce n'est pas le seul avantage des procédures stockées sur le code SQL (Sécurité, Recompilation, Round-Trip ...)

Citation:

---

Envoyé par Philippe Vialatte

En fait, je dirais même que si un projet n'est pas basé *uniquement* sur des SP, il vaut mieux avoir un ORM bien fichu, qui va automatiquement faire des requêtes paramétrées, maintenir un cache, proposer des transactions, etc, que de faire du SQL à la main (ce qui est mal fat dans 60% des cas...)

---

C'est clair que par promolution, c'est le raisonnement normal d'un Developpeur, nulle doute.

Citation:

---

Envoyé par Philippe Vialatte

En fait, je dirais même que si un projet n'est pas basé *uniquement* sur des SP, il vaut mieux avoir un ORM bien fichu, qui va automatiquement faire des requêtes paramétrées, maintenir un cache, proposer des transactions, etc, que de faire du SQL à la main (ce qui est mal fat dans 60% des cas...)

---

Et l'ORM va également optimiser le traffic réseau, lors de l'envoie de la requête.

Citation:

---

Envoyé par Philippe Vialatte

M'enfin, si je me trompe, tirez pas, je suis pas DBA

---

Non, nous n'allons pas te fusier, tu peux te rassurer cher ami.

Citation:

---

Envoyé par iberserk

Oui la requête était mauvaise, LINQ n'inventant rien il suffit par exemple de regarder la requete que génère LINQ avec votre GetById pour voir la 'bonne requête'.

---

Et je doute fort que la requête ait été écrite par un DBA (Bon), ce qui n'est que normal.

Citation:

---

Envoyé par iberserk

Mais cela appuis votre argumentaire qui dis qu'un bon "dev orm" prévaut dans le cas ou le SQL n'est pas maitrisé.
En clair: tester les performances au fur et a mesure des devs (sql profiler) est indispensable.

---

Je doute fort que vous puissiez être un bon dev orm si vous ne maîtriser pas le language SQL et les principes de bases des SGBDR, L'ORM n'étant qu'un outils permettant de faire des requêtes SQL via le code Object.

Citation:

---

Envoyé par iberserk

Sur les 4/5 développeurs qui sont loins d'être débutants, aucun ne sait utiliser LINQ correctement...

---

Puisse que c'est une techno récente qui n'est pas enseignée et il nous faut un peu de temps pour arriver à le maîtriser mais aussi j'ose insister qu'il faut du temps.

Citation:

---

Envoyé par Er3van

En prenant également un peu de hauteur, il faut aussi prendre en compte le fait que stratégiquement, les développeurs de demain n'auront peut-être plus vocation à savoir faire du SQL - d'autant qu'ils seront de moins en moins des "occidentaux" - ce sera le rôle des seuls DBA, qui feront d'ailleurs peut-être surement de plus en plus de conseil au niveau des ORM.

---

Faut il comprendre que les occidentaux sont meilleurs en sql ? 8O

D’après tout ce qui a été dis, chacun défend son domaine d'activité, pour ne pas sous-estimer sa profession(développeur DOT.NET, Architectes de BD), c'est tout!

Si un architecte de BD qui parle dans ce forum, avait été développeur au lieu de DBA, même si c'est la même personne, il aurait défendu les ORM (et inversement...).

C'est tout a fait normal :ccool:.

Donc, pour avoir un avis concret et loin de préférences professionnels, il faut demander à une personne qui n'a pas encore de préférences professionnels (un étudiant en informatique par exemple).

Pour moi qui en est un, je crois que les ORM ont été fais pour faciliter le travail des développeurs dans des applications complexes, non pas pour pour démontrer que les développeurs ont un faible en sql et essayer de le contrer en faisant des ORM une alternative, mais pour atteindre le but que les informaticiens essayent quotidiennement d'atteindre: réaliser des performances efficaces en un minimum de temps et avec le moindre coût. Et c'est d'ailleurs la règle numéro 1, dans l’organisation des entreprises: raison d’être d'un développeur.

En fin de compte, *c'est vrai que que les développeurs ne peuvent pas s'en passer des DBAs mais je précise que rien ne vaut de travailler avec un outil "compliqué,selon les DBAs: le sql" alors qu'il existe des solutions (ORM) qui aboutissent au même résultat à la fin, rien que pour demontrer ce principe* et montrer que les DBAs sont plus qualifiés que les développeurs.
En plus, les DBAs peuvent aussi travailler avec les ORMs puisqu'ils sont proches de sql, cela permettra de gagner du temps sans pour autant s'en passer des DBAs, car malgré tout, si un developpeur est nul en sql(ce qui n'est pas souvent le cas), il le sera aussi pour les ORM (chose sur).
Un développeur qui utilise les ORMs n'est pas à sous-estimer car il utilise "sql" d'une manière ou d'une autre. :ccool:

Citation:

---

Puisse que c'est une techno récente qui n'est pas enseignée et il nous faut un peu de temps pour arriver à le maîtriser mais aussi j'ose insister qu'il faut du temps.

---

Tout est relatif tout de même... LINQ TO SQL et EF commence a dater de 4/5 ANS tout de même.
Mais on peut convenir que ça reste des frameworks récents certes...

Citation:

---

En fin de compte, *c'est vrai que que les développeurs ne peuvent pas s'en passer des DBAs mais je précise que rien ne vaut de travailler avec un outil "compliqué,selon les DBAs: le sql" alors qu'il existe des solutions (ORM) qui aboutissent au même résultat à la fin, rien que pour demontrer ce principe* et montrer que les DBAs sont plus qualifiés que les développeurs.

---

Oui alors ça... ça se discute encore... vision souvent court terme inhérente à une réalité de deadline de delivery...

Je peut vous dire que quand vous allez un an plus tard intervenir a grand frais chez un de vos clients pour 'auditer ce qui ne va pas car plus rien n'avance' et que vous lui dites: oui ben l'equipe de dev étaient pressé et n'a rien testé en terme de perf (lazy loading dans tout les sens dans des foreach donc 1000 résultats de recherche= 2001 (noté le 1) requêtes car il faut récupérer Client.EtatCivil.NomEtatCivil et Client.Commandes.count().toString()).

Et bien vous faites moins le malin... et c'est du vécu...


Vous ne m’enlèverez pas de l'idée qu'un ORM est vicieux pour un développeur junior... et s'ils ne sont pas encadrés (et vous autres experts n'avez pas toujours le temps octroyé nécessaire pour vérifier ces dérives au fil de l'eau...) et bien prions que l'application ne monte pas en volume et soit peu sollicitée...

Si je devais en conclusion personnelle définir ma pensée sur les ORM je dirais:

Pratique quand on est pressé pour de petites applications, a proscrire quand on recherche la performance absolue.
Le problème étant que cet aspect est en général le dernier des soucis lors des dev (base de test en inadéquation totale avec la base de prod en terme de volumétrie, tests mono utilisateur...).
NB: LINQ TO SQL/ENTITIES ont été bannis chez CDISCOUNT... pas en adéquation avec les sollicitations intensives des BDD.

Citation:

---

D’après tout ce qui a été dis, chacun défend son domaine d'activité, pour ne pas sous-estimer sa profession

---

Mais détrompez vous, j'ai une grande admiration pour les expert/architecte .NET.. venant moi même de ce monde là.