LINQ-to-SQL vs procédures stockées ?[fermé]

StackOverflow https://stackoverflow.com/questions/14530

Question

J'ai jeté un œil à l'article "Guide du débutant sur LINQ" ici sur StackOverflow (Guide du débutant sur LINQ), mais j'avais une question complémentaire :

Nous sommes sur le point de lancer un nouveau projet dans lequel presque toutes nos opérations de base de données seront des récupérations de données assez simples (il y a un autre segment du projet qui écrit déjà les données).Jusqu'à présent, la plupart de nos autres projets utilisent des procédures stockées pour de telles choses.Cependant, j'aimerais tirer parti de LINQ-to-SQL si cela a plus de sens.

Donc la question est la suivante :Pour les récupérations de données simples, quelle approche est la meilleure, LINQ-to-SQL ou procédures stockées ?Des avantages ou des inconvénients spécifiques ?

Merci.

Était-ce utile?

La solution

Quelques avantages de LINQ par rapport aux sprocs :

  1. Type de sécurité:Je pense que nous comprenons tous cela.
  2. Abstraction:Cela est particulièrement vrai avec LINQ vers les entités.Cette abstraction permet également au framework d'ajouter des améliorations supplémentaires dont vous pouvez facilement profiter. PLINQ est un exemple d'ajout du support multithread à LINQ.Les modifications de code sont minimes pour ajouter cette prise en charge.Il serait BEAUCOUP plus difficile de créer ce code d'accès aux données qui appelle simplement des sprocs.
  3. Prise en charge du débogage:Je peux utiliser n'importe quel débogueur .NET pour déboguer les requêtes.Avec les sprocs, vous ne pouvez pas déboguer facilement le SQL et cette expérience est largement liée au fournisseur de votre base de données (MS SQL Server fournit un analyseur de requêtes, mais cela ne suffit souvent pas).
  4. Indépendant du fournisseur:LINQ fonctionne avec de nombreuses bases de données et le nombre de bases de données prises en charge ne fera qu'augmenter.Les Sprocs ne sont pas toujours portables entre les bases de données, soit en raison de différences de syntaxe ou de prise en charge des fonctionnalités (si la base de données prend en charge les sprocs).
  5. Déploiement:D'autres l'ont déjà mentionné, mais il est plus facile de déployer un seul assembly que de déployer un ensemble de sprocs.Cela rejoint également le numéro 4.
  6. Plus facile:Vous n'avez pas besoin d'apprendre T-SQL pour accéder aux données, ni l'API d'accès aux données (par ex.ADO.NET) nécessaire pour appeler les sprocs.Ceci est lié aux numéros 3 et 4.

Quelques inconvénients de LINQ par rapport aux sprocs :

  1. Trafic réseau:Les sprocs n'ont besoin que de sérialiser le nom du sproc et les données d'argument sur le réseau pendant que LINQ envoie l'intégralité de la requête.Cela peut devenir très grave si les requêtes sont très complexes.Cependant, l'abstraction de LINQ permet à Microsoft d'améliorer cela au fil du temps.
  2. Moins flexible:Sprocs peut tirer pleinement parti des fonctionnalités d'une base de données.LINQ a tendance à être plus générique dans son support.Ceci est courant dans tout type d'abstraction de langage (par ex.C# contre assembleur).
  3. Recompilation:Si vous devez modifier la façon dont vous accédez aux données, vous devez recompiler, versionner et redéployer votre assembly.Les Sprocs peuvent parfois permettre à un administrateur de base de données d'ajuster la routine d'accès aux données sans avoir besoin de redéployer quoi que ce soit.

La sécurité et la gérabilité sont également des sujets de controverse.

  1. Sécurité:Par exemple, vous pouvez protéger vos données sensibles en limitant directement l'accès aux tables et en plaçant des ACL sur les sprocs.Avec LINQ, cependant, vous pouvez toujours restreindre l'accès direct aux tables et placer les ACL sur une table pouvant être mise à jour. vues pour atteindre un objectif similaire (en supposant que votre base de données prend en charge les vues pouvant être mises à jour).
  2. Gérabilité:L'utilisation de vues vous donne également l'avantage de protéger votre application de manière ininterrompue contre les modifications de schéma (comme la normalisation des tables).Vous pouvez mettre à jour la vue sans nécessiter la modification de votre code d'accès aux données.

J'étais un grand gars de sproc, mais je commence à me tourner vers LINQ comme une meilleure alternative en général.S'il y a certains domaines dans lesquels les sprocs sont clairement meilleurs, alors j'écrirai probablement toujours un sproc mais j'y accéderai en utilisant LINQ.:)

Autres conseils

Je suis généralement partisan de tout mettre dans des procédures stockées, pour toutes les raisons que les administrateurs de base de données insistent depuis des années.Dans le cas de Linq, il est vrai qu'il n'y aura aucune différence de performances avec de simples requêtes CRUD.

Mais gardez quelques points à l’esprit lorsque vous prenez cette décision :l'utilisation de n'importe quel ORM vous lie étroitement à votre modèle de données.Un administrateur de base de données n'a pas la liberté d'apporter des modifications au modèle de données sans vous obliger à modifier votre code compilé.Avec les procédures stockées, vous pouvez masquer ce type de modifications dans une certaine mesure, car la liste de paramètres et les jeux de résultats renvoyés par une procédure représentent son contrat, et les entrailles peuvent être modifiées, tant que ce contrat est toujours respecté. .

De plus, si Linq est utilisé pour des requêtes plus complexes, le réglage de la base de données devient une tâche beaucoup plus difficile.Lorsqu'une procédure stockée s'exécute lentement, l'administrateur de base de données peut se concentrer totalement sur le code de manière isolée et dispose de nombreuses options, juste pour que le contrat soit toujours satisfait une fois qu'il a terminé.

J'ai vu de très nombreux cas où de graves problèmes dans une application étaient résolus par des modifications du schéma et du code dans les procédures stockées sans aucune modification du code déployé et compilé.

Peut-être qu'une approche hybride serait bien avec Linq ?Linq peut bien entendu être utilisé pour appeler des procédures stockées.

Linq vers SQL.

Le serveur SQL mettra en cache les plans de requête, il n'y a donc aucun gain de performances pour les sprocs.

Vos instructions Linq, en revanche, feront logiquement partie de votre application et seront testées avec elle.Les Sprocs sont toujours un peu séparés et sont plus difficiles à maintenir et à tester.

Si je travaillais sur une nouvelle application à partir de zéro en ce moment, j'utiliserais simplement Linq, sans sprocs.

Pour la récupération de données de base, j'opterais pour Linq sans hésitation.

Depuis que j'ai déménagé chez Linq, j'ai trouvé les avantages suivants :

  1. Déboguer mon DAL n'a jamais été aussi simple.
  2. La sécurité du temps de compilation lorsque votre schéma change n'a pas de prix.
  3. Le déploiement est plus facile car tout est compilé dans des DLL.Plus besoin de gérer les scripts de déploiement.
  4. Étant donné que Linq peut prendre en charge l'interrogation de tout ce qui implémente l'interface IQueryable, vous pourrez utiliser la même syntaxe pour interroger XML, les objets et toute autre source de données sans avoir à apprendre une nouvelle syntaxe.

LINQ va gonfler le cache des procédures

Si une application utilise LINQ to SQL et que les requêtes impliquent l'utilisation de chaînes dont la longueur peut être très variable, le cache de procédures SQL Server deviendra saturé avec une version de la requête pour chaque longueur de chaîne possible.Par exemple, considérons les requêtes très simples suivantes créées sur la table Person.AddressTypes dans la base de données AdventureWorks2008 :

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

Si ces deux requêtes sont exécutées, nous verrons deux entrées dans le cache de procédures SQL Server :L'un lié à un NVARCHAR(7) et l'autre à un NVARCHAR(11).Imaginez maintenant s'il y avait des centaines ou des milliers de chaînes d'entrée différentes, toutes avec des longueurs différentes.Le cache de procédures serait inutilement rempli de toutes sortes de plans différents pour exactement la même requête.

Plus ici: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Je pense que l'argument pro LINQ semble venir de personnes qui n'ont pas d'antécédents en matière de développement de bases de données (en général).

Surtout si vous utilisez un produit comme VS DB Pro ou Team Suite, la plupart des arguments avancés ici ne s'appliquent pas, par exemple :

Plus difficile à maintenir et à tester :VS fournit une vérification complète de la syntaxe, une vérification du style, une vérification des référentiels et des contraintes, etc.Il fournit également des capacités complètes de tests unitaires et des outils de refactorisation.

LINQ rend les véritables tests unitaires impossibles car (dans mon esprit) il échoue au test ACID.

Le débogage est plus facile dans LINQ :Pourquoi?VS permet une intervention complète à partir du code managé et un débogage régulier des SP.

Compilé dans une seule DLL plutôt que dans des scripts de déploiement :Une fois de plus, VS vient à la rescousse en pouvant créer et déployer des bases de données complètes ou apporter des modifications incrémentielles sécurisées aux données.

Vous n'avez pas besoin d'apprendre TSQL avec LINQ :Non, ce n'est pas le cas, mais vous devez apprendre LINQ - où est l'avantage ?

Je ne vois vraiment pas cela comme un avantage.Être capable de changer quelque chose de manière isolée peut sembler une bonne chose en théorie, mais ce n'est pas parce que les modifications remplissent un contrat que cela renvoie les bons résultats.Pour pouvoir déterminer quels sont les résultats corrects, vous avez besoin d'un contexte et vous obtenez ce contexte à partir du code appelant.

Euh, les applications faiblement couplées sont l'objectif ultime de tous les bons programmeurs, car elles augmentent réellement la flexibilité.Être capable de changer les choses de manière isolée est fantastique, et ce sont vos tests unitaires qui garantiront qu'ils renvoient toujours des résultats appropriés.

Avant que vous ne vous énerviez tous, je pense que LINQ a sa place et a un grand avenir.Mais pour les applications complexes et gourmandes en données, je ne pense pas que cela soit prêt à remplacer les procédures stockées.C'était un point de vue auquel j'avais fait écho par un MVP de TechEd cette année (ils resteront anonymes).

MODIFIER:Le côté procédure stockée LINQ to SQL est quelque chose sur lequel je dois encore en savoir plus - en fonction de ce que je trouve, je peux modifier ma diatribe ci-dessus ;)

LINQ est nouveau et a sa place.LINQ n'est pas inventé pour remplacer les procédures stockées.

Ici, je vais me concentrer sur certains mythes et inconvénients en matière de performances, juste pour "LINQ to SQL", bien sûr, je peux me tromper totalement ;-)

(1) Les gens disent que la déclaration LINQ peut être « mise en cache » dans le serveur SQL, afin de ne pas perdre de performances.Partiellement vrai."LINQ to SQL" est en fait le moteur d'exécution traduisant la syntaxe LINQ en instruction TSQL.Ainsi, du point de vue des performances, une instruction SQL ADO.NET codée en dur n'a aucune différence avec LINQ.

(2) À titre d'exemple, une interface utilisateur de service client dispose d'une fonction de « transfert de compte ».cette fonction elle-même peut mettre à jour 10 tables de base de données et renvoyer certains messages d'un seul coup.Avec LINQ, vous devez créer un ensemble d'instructions et les envoyer en un seul lot au serveur SQL.les performances de ce lot LINQ->TSQL traduit peuvent difficilement correspondre à la procédure stockée.Raison?étant donné que vous pouvez modifier la plus petite unité de l'instruction dans la procédure stockée à l'aide du profileur SQL intégré et de l'outil de plan d'exécution, vous ne pouvez pas le faire dans LINQ.

Le fait est que lorsqu’on parle d’une seule table de base de données et d’un petit ensemble de données CRUD, LINQ est aussi rapide que SP.Mais pour une logique beaucoup plus compliquée, la procédure stockée est plus modifiable en termes de performances.

(3) "LINQ to SQL" incite facilement les débutants à introduire des porcs de performances.N'importe quel responsable TSQL peut vous dire quand ne pas utiliser CURSOR (en gros, vous ne devriez pas utiliser CURSOR dans TSQL dans la plupart des cas).Avec LINQ et la charmante boucle "foreach" avec requête, il est si simple pour un débutant d'écrire un tel code :

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Vous pouvez voir que ce code simple et décent est si attrayant.Mais sous le capot, le runtime .NET traduit simplement cela en un lot de mise à jour.S'il n'y a que 500 lignes, il s'agit d'un lot TSQL de 500 lignes ;S'il y a des millions de lignes, c'est un succès.Bien sûr, un utilisateur expérimenté n'utilisera pas cette méthode pour effectuer ce travail, mais le fait est qu'il est si facile de tomber dans cette voie.

Le meilleur code n'est pas du code, et avec les procédures stockées, vous devez écrire au moins du code dans la base de données et du code dans l'application pour l'appeler, alors qu'avec LINQ to SQL ou LINQ to Entities, vous n'avez pas besoin d'écrire de code supplémentaire. code au-delà de toute autre requête LINQ en dehors de l'instanciation d'un objet contextuel.

LINQ a définitivement sa place dans les bases de données spécifiques aux applications et dans les petites entreprises.

Mais dans une grande entreprise, où les bases de données centrales servent de centre de données communes pour de nombreuses applications, nous avons besoin d’abstraction.Nous devons gérer la sécurité de manière centralisée et afficher les historiques d’accès.Nous devons être capables de faire une analyse d’impact :si j'apporte une légère modification au modèle de données pour répondre à un nouveau besoin commercial, quelles requêtes doivent être modifiées et quelles applications doivent être retestées ?Les vues et les procédures stockées me donnent cela.Si LINQ peut faire tout cela et rendre nos programmeurs plus productifs, j'en serai heureux : quelqu'un a-t-il une expérience de son utilisation dans ce type d'environnement ?

Un DBA n'a pas la liberté d'apporter des modifications au modèle de données sans vous forcer à modifier votre code compilé.Avec les procédures stockées, vous pouvez masquer ces types de modifications dans une mesure, car la liste des paramètres et les résultats des résultats sont retournés d'une procédure représentent son contrat, et les entrailles peuvent être modifiées, tant que ce contrat est toujours atteint .

Je ne vois vraiment pas cela comme un avantage.Être capable de changer quelque chose de manière isolée peut sembler une bonne chose en théorie, mais ce n'est pas parce que les modifications remplissent un contrat que cela renvoie les bons résultats.Pour pouvoir déterminer quels sont les résultats corrects, vous avez besoin d'un contexte et vous obtenez ce contexte à partir du code appelant.

À mon humble avis, RAD = LINQ, RUP = Procs stockés.J'ai travaillé pour une grande entreprise Fortune 500 pendant de nombreuses années, à plusieurs niveaux, y compris la direction, et franchement, je n'embaucherais jamais des développeurs RUP pour faire du développement RAD.Ils sont tellement cloisonnés qu’ils ont une connaissance très limitée de ce qu’il faut faire aux autres niveaux du processus.Dans un environnement cloisonné, il est logique de donner aux administrateurs de base de données le contrôle des données via des points d'entrée très spécifiques, car d'autres ne connaissent franchement pas les meilleurs moyens de gérer les données.

Mais les grandes entreprises déménagent douloureusement lent dans le domaine du développement, ce qui est extrêmement coûteux.Il y a des moments où vous devez aller plus vite pour économiser du temps et de l'argent, et LINQ fournit cela et bien plus encore.

Parfois, je pense que les administrateurs de base de données ont un parti pris contre LINQ parce qu'ils estiment que cela menace leur sécurité d'emploi.Mais c'est la nature de la bête, mesdames et messieurs.

Je pense que vous devez utiliser des procédures pour tout ce qui est réel.

A) Écrire toute votre logique dans Linq signifie que votre base de données est moins utile car seule votre application peut la consommer.

B) De toute façon, je ne suis pas convaincu que la modélisation objet soit meilleure que la modélisation relationnelle.

C) Tester et développer une procédure stockée dans SQL est bien plus rapide qu'un cycle d'édition de compilation dans n'importe quel environnement Visual Studio.Vous venez d'éditer, F5 et appuyez sur Sélectionner et vous partez pour les courses.

D) Il est plus facile de gérer et de déployer des procédures stockées que des assemblys.vous venez de mettre le fichier sur le serveur et d'appuyer sur F5...

E) Linq to SQL écrit toujours du code merdique parfois lorsque vous ne vous y attendez pas.

Honnêtement, je pense que l'ultime solution serait que MS augmente t-sql afin qu'il puisse effectuer une projection de jointure implicite comme le fait Linq.t-sql devrait savoir si vous vouliez faire order.lineitems.part, par exemple.

LINQ n'interdit pas l'utilisation de procédures stockées.J'ai utilisé le mode mixte avec LINQ-SQL et LINQ-storedproc.Personnellement, je suis content de ne pas avoir à écrire les processus stockés... pwet-tu.

Il y a également la question d’un éventuel retour en arrière de la version 2.0.Croyez-moi, cela m'est arrivé plusieurs fois, donc je suis sûr que cela est arrivé à d'autres.

Je suis également d'accord que l'abstraction est la meilleure.Parallèlement, le but initial d'un ORM est de faire en sorte que les SGBDR correspondent bien aux concepts OO.Cependant, si tout fonctionnait bien avant LINQ en devant s'écarter un peu des concepts OO, alors foutez-les.Les concepts et la réalité ne font pas toujours bon ménage.Il n’y a pas de place pour les fanatiques militants dans l’informatique.

Je suppose que tu veux dire Linq To Sql

Pour n'importe quelle commande CRUD, il est facile de profiler les performances d'une procédure stockée par rapport à.n'importe quelle technologie.Dans ce cas, la différence entre les deux sera négligeable.Essayez de profiler un objet de champ à 5 (types simples) sur 100 000 requêtes de sélection pour savoir s'il existe une réelle différence.

D'un autre côté, le véritable facteur décisif sera la question de savoir si vous vous sentez à l'aise ou non de mettre votre logique métier dans votre base de données, ce qui est un argument contre les procédures stockées.

Selon les gourous, je définis LINQ comme une moto et SP comme une voiture.Si vous souhaitez faire un court voyage et n'avoir que de petits passagers (dans ce cas 2), optez gracieusement avec LINQ.Mais si vous voulez partir en voyage et avoir un grand groupe, je pense que vous devriez choisir SP.

En conclusion, le choix entre une moto ou une voiture dépend de votre itinéraire (affaires), de la durée (temps) et des passagers (données).

J'espère que cela aide, je peux me tromper.:D

Toutes ces réponses penchant vers LINQ parlent principalement de FACILITÉ de DÉVELOPPEMENT qui est plus ou moins liée à une mauvaise qualité de codage ou à une paresse de codage.Je suis comme ça seulement.

Certains avantages de Linq, je lis ici comme étant faciles à tester, faciles à déboguer, etc., mais ceux-ci ne sont nulle part connectés à la sortie finale ou à l'utilisateur final.Cela va toujours causer des problèmes à l'utilisateur final en termes de performances.Quel est l'intérêt de charger beaucoup de choses en mémoire, puis d'appliquer des filtres lors de l'utilisation de LINQ ?

Encore une fois, TypeSafety met en garde contre le fait que "nous faisons attention à éviter une mauvaise conversion de type", ce que nous essayons d'améliorer encore une fois en utilisant Linq.Même dans ce cas, si quelque chose change dans la base de données, par ex.taille de la colonne String, alors linq doit être recompilé et ne serait pas sécurisé sans cela ..J'ai essayé.

Bien que nous ayons trouvé que c'était bon, agréable, intéressant, etc. en travaillant avec LINQ, cela présente le net inconvénient de rendre le développeur paresseux :) et il est prouvé 1000 fois qu'il est mauvais (peut-être pire) en termes de performances par rapport aux processus stockés.

Ne sois pas paresseux.J'essaie dur.:)

Processus stockés vs code (Discussion précédente)

Pour les opérations CRUD simples avec un seul point d'accès aux données, je dirais d'opter pour LINQ si vous vous sentez à l'aise avec la syntaxe.Pour une logique plus compliquée, je pense que les sprocs sont plus efficaces en termes de performances si vous maîtrisez T-SQL et ses opérations plus avancées.Vous bénéficiez également de l'aide de Tuning Advisor, de SQL Server Profiler, du débogage de vos requêtes à partir de SSMS, etc.

La procédure stockée facilite les tests et vous pouvez modifier la requête sans toucher au code de l'application.De plus, avec Linq, obtenir des données ne signifie pas que ce sont les bonnes données.Et tester l'exactitude des données signifie exécuter l'application, mais avec une procédure stockée, il est facile de tester sans toucher à l'application.

Le résultat peut être résumé ainsi

LinqToSql pour les petits sites et les prototypes.Cela fait vraiment gagner du temps pour le prototypage.

SP :Universel.Je peux affiner mes requêtes et toujours vérifier ActualExecutionPlan/EstimatedExecutionPlan.

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

LINQ et SQL ont tous deux leur place.Les deux ont leurs inconvénients et leurs avantages.

Parfois, pour la récupération de données complexes, vous aurez peut-être besoin de procédures stockées.Et parfois, vous souhaiterez peut-être que d'autres personnes utilisent votre procédure stockée dans Sql Server Management Studio.

Linq to Entities est idéal pour le développement CRUD rapide.

Bien sûr, vous pouvez créer une application en utilisant uniquement l’un ou l’autre.Ou vous pouvez le mélanger.Tout dépend de vos exigences.Mais les processus stockés SQL ne disparaîtront pas de si tôt.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top