Discussion :

[hmimoud]

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.

Je suis totalement d'accord avec vous sur cet inconvénient des ORM, ce que j'ai voulu dire par contre, c'est qu'il ne faut pas penser que le développeur utilise les ORM rien que pour éviter de tomber dans la dite "complexité" de sql.

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

Ok, mais vous restez toujours un architecte de BD, et vous ne travaillez pas avec les ORM.
C'est juste un constat que j'ai fais de la discussion, si vous parcourez la discussion du début jusqu'à la fin, vous verrez que tout ce qui ont été contre les ORMs sont des architectes de BD. et tout ce qui ont été pour, sont des développeurs, quant à moi je ne fais que donner mon avis sur ce qui a été dis

[iberserk]

Ok, mais vous restez toujours un architecte de BD, et vous ne travaillez pas avec les ORM

Que dieu dans sa grande miséricorde vous pardonne cet erreur (bon ok après ce post je vais me coucher) je travaille avec tout les jours...

[hmimoud]

Bon, ce n'est pas très grave , comme j'ai dis c'est juste un constat que j'ai fais.
Je ne comprend pas pourquoi depuis le début de la discussion vous énumérer les inconvénients des ORM et malgré ça vous travaillez avec, alors que, étant un DBA, vous pouvez travaillez avec les instructions sql .

Bonne nuit iberserk

[iberserk]

Je ne comprend pas pourquoi depuis le début de la discussion vous énumérer les inconvénients des ORM et malgré ça vous travaillez avec, alors que, étant un DBA, vous pouvez travaillez avec les instructions sql

Car j'ai la chance d'avoir le dernier mot dans la société dans laquelle je travaille en terme d'accès aux données... sauf sur l'ORM puisque l'appli avait déjà un an quand je suis arrivé...

Il y avait d'ailleurs déjà quelques lenteurs chez certains client qui commençaient à avoir une volumétrie moyenne (table de 20 millions de lignes assez sollicitée...).
Je travaille donc non seulement sur la BDD mais aussi sur la DAL du projet .NET ainsi que sur la mise en cache des données dans le cache IIS.

Résultat: 7 fois moins de requêtes envoyées sur le serveur...

[WOLO Laurent]

Vous ne m’enlèverez pas de l'idée qu'un ORM est vicieux pour un développeur junior...

Bravo; si tu étais à mes côtés, j'allais t'embrasser. Je veux entendre cela de la bouche d'un developpeur de la taille de phillipe Vialette.

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.

La aussi plus un point pour toi.

[WOLO Laurent]

Bon, ce n'est pas très grave , comme j'ai dis c'est juste un constat que j'ai fais.
Je ne comprend pas pourquoi depuis le début de la discussion vous énumérer les inconvénients des ORM et malgré ça vous travaillez avec, alors que, étant un DBA, vous pouvez travaillez avec les instructions sql .

Bonne nuit iberserk

Je les apprends, pour être à la page mais je ne les utilisent jamais ! Un ORM, pour moi, c'est le meilleur moyen de faire une application performante à court terme.

[Philippe Vialatte]

Je veux entendre cela de la bouche d'un developpeur de la taille de phillipe Vialette.

Hmmm...

Je suis pas prêt de le dire si tu écorches mon nom comme ca

Sur le fond, je suis d'accord, un ORM peut être mal utilisé...mais les instructions SQL aussi, et parfois avec un impact plus grave

Le fond du problème, que ce soit au niveau d'un ORM ou au niveau d'une procédure stockée (qui peut aussi être codée porcivement, être un gouffre de performance), c'est l'utilisation d'un outil par quelqu'un qui ne le maîtrise pas. Un développeur qui maîtrise un ORM aura un gros gain de temps de dev, une augmentatino de la maintenabilité, et pas ou peu de perte de perfs (biscotte sur une requête biscornue, il fera une procedure stockée, et qu'il fera gaffe au lazy loading et au select N+1)

...et oui, je passe 25% de mon temps à relire le code de 2 équipes de DEV, a passer du SQL profiler, à jouer sur les indexs, et à faire des tests de charge sur la DB...

[hmimoud]

Je rappelle que cette discussion est une occasion à chacun pour donner son avis et aussi pour s'informer et élargir le champ de réflexion concernant ce sujet. Je tiens à remercier tout ce qui ont participer à cette discussion, et se sont exprimé en mettant en cause leurs expérience. Cela apportera une grande aide et donnera une idée claire aux informaticiens en général qui veulent travailler avec les ORM (dont linq to sql), pour prendre une décision. N’hésitez pas à continuer .

[WOLO Laurent]

Hmmm...
Je suis pas prêt de le dire si tu écorches mon nom comme ca

Désolé, Philippe Vialatte, j'ai pas relu mon texto, je te demande pardon.

Hmmm...
Sur le fond, je suis d'accord, un ORM peut être mal utilisé...mais les instructions SQL aussi, et parfois avec un impact plus grave

Là aussi, avouons le, utilisation par des personnes non experimentées qui ne prennent pas le temps ou ne maîtrise pas les fondements. Depuis que nous faisons trop usage des généralistes dans nos projets, nous croyons faire des économies mais sur le court terme et il peut même arriver que le Data Layer soit completement reécrit.

[Er3van]

Faut il comprendre que les occidentaux sont meilleurs en sql ?

Non, pas nécessairement, même si aujourd'hui un développeur lambda Américain ou Français sera "généralement" plus performant qu'un Argentin ou un Indien : dans 10 ça ne sera plus vrai.

Par contre il y a plein de contraintes, liées notamment à la distance, qui font que les dév offshore (voire nearshore) sont de moins bonne qualité : par expérience, c'est encore plus flagrant quand un ORM est utilisé, car il se peut que le modèle de données soit fait à 10 000 km de l'endroit où le développement sera fait..

EDIT : +1 pour Philippe.

[Immobilis]

Salut à tous,

Je travaille donc non seulement sur la BDD mais aussi sur la DAL du projet .NET ainsi que sur la mise en cache des données dans le cache IIS.

Voici qui résume bien la situation. La performance d'une application ne se situe pas à un seul niveau et il faut que chaque membre d'un projet considère cette question et fasse des tests. Faut-il mettre les données en cache ou non, faut-il utiliser un dictionnaire, une liste, une collection, une Hashtable? Le role du DBA est avant tout d'optimiser la base, index, taille des champs, taille des tables, requêtes... Si tu t’intéresse au reste c'est très bien.

Récemment, j'ai travaillé avec une personne qui disait en substance qu'il ne s'occuperait de la performance de son application que si elle montrait des signes de faiblesse. Il préférait augmenter le nombre de serveurs que de considérer le code... Il a tout de même bien fallu qu'il s'attaque au problème. Je l'ai vu faire la chasse au millisecondes parce qu'il était content de pouvoir les récupérer

J'utilise LINQ to SQL et j'en suis très content. Il faut juste comprendre un peu ce que l'on fait. Pour l'avoir testé, les performances de LINQ sont excellentes quand les requêtes sont compilées. On l'oublie trop souvent. L'avantage de LINQ est des DataContext est qu'ils se trouvent du côté du code et qu'ils font un excellent pont entre la base de données et le code. LINQ peut être mis sous contrôle de source et on peut tout à fait l'encapsuler dans une DAL. LINQ to SQL permet d'obtenir des Enumerables qu'on requêtera avec LINQ to Entities.

LINQ to SQL n'est pas le seul moyen mais c'est un excellent moyen. Je l'ai utilisé sur de gros sites de commerce électronique.

A+

[WOLO Laurent]

Que dites-vous de ca ?

En général les deadlock sont du à un mauvais développement des applications :
1) transactions inutiles
2) verrouillage explicite
3) pilotage incorrecte du niveau d'isolation des transactions.
Et surtout lorsque les applications sont écrites à l'aide de d'ORM ou de Framework catastrophiques comme Hibernate par exemple. A lire : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

Pour les détecter, utilisez le profiler SQL et tracez les événements de deadlock.
Voir : http://sqlpro.developpez.com/sqlserv...ge=tsql#LIII-M

Ensuite il vous faudra remonter cela aux développeurs et surtout commencer par les former !!!!!!!!

A +

Vous pouvez le retrouver sur ce lien
Vous conviendez que je suis vraiment indulgent.

[SQLpro]

Que pensez vous de linq to sql ?
Merci

Rien !!!!

PUISQU'IL A ÉTÉ ABANDONNÉ pas son créateur Microsoft !!!!!

A lire :
http://patricelamarche.net/2008/11/0...st-mort-suite/

Bien évidemment ce que je pense des ORM pour les avoir cotoyés dans de nombreux audit et vu des sociétés faire faillite à cause de ce genre de merde est assez simple et a été dit maint fois par d'autre :
L'ORM est le Vietnâm de l'informatique
Tout le monde s'y met parce que ça semble fastoche et finalement s'y embourbe et ça coute dix fois plus cher en maintenance !

A +

[Er3van]

L'ORM est le Vietnâm de l'informatique
Tout le monde s'y met parce que ça semble fastoche et finalement s'y embourbe et ça coute dix fois plus cher en maintenance !

Cela a été débattu longuement ici, et je trouve cette vision très partiale et réductrice... Comme cela été dit, dans un contexte donné, et avec un niveau de compétences et de qualité suffisant (cela fait quand même des contraintes fortes), utiliser des ORM est tout à fait viable.

[Philippe Vialatte]

Tiens, un troll

Rien !!!!

PUISQU'IL A ÉTÉ ABANDONNÉ pas son créateur Microsoft !!!!!

A lire :
http://patricelamarche.net/2008/11/0...st-mort-suite/

Mouais...
http://msdn.microsoft.com/en-us/data/bb525059.aspx#Q3

vu des sociétés faire faillite à cause de ce genre de merde

Hmmm....donc, utiliser mal un outil veut dire qu'il est fondamentalement mauvais...

Sous entendu, je peux faire une procédure stockée qui me plante la db, ou une requête SQL qui fait un delete en oubliant le Where, donc SQL est mauvais, c'est ca l'idée ???

Personnellement, j'ai vu des sociétés faire faillite à cause:
- de mauvais placements (arrêtons de mettre des sociétés en bourse)
- de mauvais choix de stratégie (arrêtons de mettre en place des stratégies)
- du décès du fondateur (arrêtons de mourir)

Plus sérieusement, oui, comme dit...euh...au tout début de la discussion, tant qu'a utiliser un ORM, autant utiliser autre chose que Linq To SQL (ne serait-ce que pour la contrainte d'utilisation de SQL Server)

Pour l'histoire du "Vietnam de l'informatique", j'en déduit que tu as lu l'article d'origine, et compris l'analyse qui était développé, à savoir que les ORM, comme tout outil (dont une base de données relationelles) ont des limites d'utilisation, et qu'une mise en place "absolue" fait rentrer l'organisation qui s'y astreint dans une situation inconfortable, à partir du moment ou ces limites sont atteintes.

...d'ou les nombreuses remarques dans les posts précédents, qui veut que, dans le cas d'un ORM, on utilise son cerveau pour l'utiliser dans les 80% des cas ou cela à un interet, et on fait autre chose dans les autres cas

[Immobilis]

Salut,

Juste pour voir, si certains d'entre vous ont du Linq to Sql dans leur applications, pouvez-vous vérifier si vous suivez les recommandations listées au bout de ce lien: http://www.sidarok.com/web/blog/cont...rformance.html

A+

[Immobilis]

Salut,

Cette discussion m'a un peu poussé à rédiger ce papier: http://immobilis.developpez.com/tuto...ity-framework/

J'y teste plusieurs implémentations de fournisseurs de données. Ce papier n'est pas encore officiellement publié et je serais très intéressé de recueillir vos commentaires, suggestions.

Merci d'avance.

Immo

[Er3van]

Très intéressant ! (Par contre c'est technique, faut s'accrocher pour suivre dans le détail, mais vu le sujet c'est logique :p)

Par contre, il serait intéressant de préciser les versions des providers (par exemple, EF 3.5, EF 4, EF 4.1 ?) et éventuellement de faire le même test avec une base "indépendante" du framework .Net comme Oracle.

[Immobilis]

Par contre, il serait intéressant de préciser les versions des providers (par exemple, EF 3.5, EF 4, EF 4.1 ?) et éventuellement de faire le même test avec une base "indépendante" du framework .Net comme Oracle.

Runtime Version: v4.0.30319;
System.Data.Linq.dll, System.Data.Entity.dll, Version: 4.0.0.0

J'ai pas Oracle... Si quelqu'un peut faire des tests pas de soucis. J'ai mis les sources dans la partie référence.

A+

[WOLO Laurent]

Vous avez écrit un excellent article qui permettrait aux personnes rigoureusent en matière de perf de pouvoir tirer meilleurs partie sur l'utilisation de linq.

Deuxièmement, d'après les tests, les fournisseurs " Linq + SP ", " Linq + Cmd " et " Linq to Entities " sont sur certains points plus rapides que le Sql traditionnel. Cela mériterait toutefois d'être testé plus en profondeur dans un environnement de production.

Toutefois il faut que tu fasses ressortir des tests qui pouverais que Linq + Cmd par exemple serait plus rapide que le SQL Standard