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

J'ai jeté un coup d'œ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 monter un nouveau projet où 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). La plupart de nos autres projets jusqu'à présent 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 extractions de données simples, quelle approche est la meilleure, LINQ-to-SQL ou procs stockés? Des avantages ou des inconvénients spécifiques?

Merci.

Quelques avantages de LINQ par rapport aux sprocs:

1. Sécurité de type : Je pense que nous comprenons tous cela.
2. Abstraction : cela est particulièrement vrai avec LINQ-to-Entities . Cette abstraction permet également au framework d'ajouter des améliorations supplémentaires dont vous pouvez facilement profiter. PLINQ est un exemple d'ajout de la prise en charge du multi-threading à LINQ. Les changements de code sont minimes pour ajouter ce support. Il serait BEAUCOUP plus difficile de faire 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 facilement déboguer le SQL et cette expérience est largement liée à votre fournisseur de 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 la syntaxe variable ou de la prise en charge des fonctionnalités (si la base de données prend en charge les sprocs du tout).
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 n ° 4.
6. Plus simple : vous n'avez pas besoin d'apprendre T-SQL pour accéder aux données, ni d'apprendre l'API d'accès aux données (par exemple ADO.NET) nécessaire pour appeler les sprocs. Ceci est lié aux numéros 3 et 4.

Quelques inconvénients de LINQ vs sprocs:

1. Trafic réseau : les sprocs n'ont besoin que de sérialiser les données de nom de sproc et d'argument sur le câble pendant que LINQ envoie la requête entière. Cela peut devenir vraiment mauvais 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 : les Sprocs peuvent 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 exemple C # vs assembleur).
3. Recompilation : si vous devez apporter des modifications à la manière dont vous accédez aux données, vous devez recompiler, mettre à jour et redéployer votre assembly. Les Sprocs peuvent parfois permettre à un DBA d'ajuster la routine d'accès aux données sans avoir à redéployer quoi que ce soit.

Les gens se disputent également la sécurité et la gérabilité.

1. Sécurité : Par exemple, vous pouvez protéger vos données sensibles en restreignant l'accès aux tables directement et en plaçant des ACL sur les sprocs. Cependant, avec LINQ, vous pouvez toujours restreindre l'accès direct aux tables et placer des ACL sur des vues de table pouvant être mises à jour pour atteindre une fin similaire (en supposant que votre base de données prenne en charge les vues pouvant être mises à jour).
2. Gérabilité : l'utilisation des vues vous donne également l'avantage de protéger votre application sans rupture des modifications de schéma (comme la normalisation de table). Vous pouvez mettre à jour la vue sans que votre code d'accès aux données ne soit modifié.

J'étais un grand gars du sproc, mais je commence à me pencher vers LINQ comme une meilleure alternative en général. S'il y a des domaines où les sprocs sont clairement meilleurs, alors j'écrirai probablement encore un sproc mais j'y accéderai en utilisant LINQ. :)

Je suis généralement partisan de mettre tout dans des procédures stockées, pour toutes les raisons que les DBA insistent depuis des années. Dans le cas de Linq, il est vrai qu'il n'y aura pas de 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 couple étroitement à votre modèle de données. Un DBA n'a aucune liberté pour 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 ces types de modifications dans une certaine mesure, car la liste de paramètres et le ou 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é .

Et aussi, 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, le DBA peut se concentrer totalement sur le code de manière isolée et dispose de nombreuses options, afin que le contrat soit toujours satisfait lorsqu'il a terminé.

J'ai vu de très nombreux cas où de graves problèmes dans une application ont été 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 hybird serait bien avec Linq? Linq peut, bien entendu, être utilisé pour appeler des procédures stockées.

Linq à Sql.

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

Vos instructions linq, en revanche, seront logiquement intégrées et testées avec votre application. 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, pas de sprocs.

Pour la récupération de données de base, je choisirais Linq sans hésitation.

Depuis mon arrivée à Linq, j'ai trouvé les avantages suivants:

1. Déboguer mon DAL n'a jamais été aussi simple.
2. La sécurité au moment de la 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. Fini la gestion des 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 du XML, des objets et toute autre source de données sans avoir à apprendre une nouvelle syntaxe.

LINQ gonflera le cache de procédure

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 gonflé avec une version de la requête pour chaque longueur de chaîne possible. Par exemple, considérez 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'une liée à 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édure deviendrait inutilement rempli de toutes sortes de plans différents pour exactement la même requête.

Plus d'informations 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, de nombreux 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 de style, une vérification des référentiels et des contraintes, etc. Il fournit également des capacités complètes de test unitaire et des outils de refactorisation.

LINQ rend les vrais 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 depuis le code managé et le 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 où il peut créer et déployer des bases de données complètes ou apporter des modifications incrémentielles sécurisées pour les données.

Pas besoin d'apprendre TSQL avec LINQ: Non, vous ne l'avez pas, mais vous devez apprendre LINQ - quel 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 bon en théorie, mais ce n'est pas parce que les changements remplissent un contrat que cela donne les bons résultats. Pour être en mesure de déterminer quels sont les résultats corrects, vous avez besoin de contexte et vous obtenez ce contexte à partir du code d'appel.

Euh, les applications faiblement couplées sont le but ultime de tous les bons programmeurs car elles augmentent vraiment la flexibilité. Être capable de changer les choses de manière isolée est fantastique, et ce sont vos tests unitaires qui garantiront que les résultats sont toujours appropriés.

Avant que vous ne vous fâchiez 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 qu'il 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 sans nom).

EDIT: Le côté procédure stockée LINQ to SQL est quelque chose que je dois encore lire 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 la procédure stockée.

Ici, je vais me concentrer sur certains mythes et inconvénients de la performance, juste pour "LINQ to SQL", bien sûr, je me trompe totalement ;-)

(1) Les gens disent que l'instruction LINQ peut "mettre en cache" dans le serveur SQL, afin qu'elle ne perde pas les performances. Partiellement vrai. "LINQ to SQL" est en fait le runtime qui traduit la syntaxe LINQ en instruction TSQL. Donc, du point de vue des performances, une instruction SQL ADO.NET codée en dur n'a aucune différence par rapport à LINQ.

(2) À titre d'exemple, une interface utilisateur de service client a une fonction «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? car 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, quand on parle de table DB unique et de 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" permet facilement aux débutants d'introduire des porcs de performance. N'importe quel senior 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 facile 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 décent facile 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 façon de faire ce travail, mais le fait est qu'il est si facile de tomber de cette manière.

Le meilleur code n'est pas de 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 code au-delà de toute autre requête LINQ en dehors de l'instanciation d'un objet de contexte.

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 plaque tournante 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 en mesure de faire une analyse d'impact: si j'apporte une petite 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 le donnent. Si LINQ peut faire tout cela et rendre nos programmeurs plus productifs, je m'en réjouirai - est-ce que quelqu'un a de l'expérience de l'utiliser dans ce type d'environnement?

Un DBA n'a aucune liberté pour 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 ces types de modifications dans une certaine mesure, car la liste de paramètres et le ou 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é .

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

IMHO, RAD = LINQ, RUP = Processus stockés. J'ai travaillé pour une grande entreprise Fortune 500 pendant de nombreuses années, à de nombreux niveaux, y compris la gestion, et franchement, je n'embaucherais jamais des développeurs RUP pour faire du développement RAD. Ils sont tellement cloisonnés qu'ils savent très peu quoi faire aux autres niveaux du processus. Avec 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 meilleures façons de gérer les données.

Mais les grandes entreprises se déplacent péniblement 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 plus encore à la pelle.

Parfois, je pense que les administrateurs de base de données sont biaisés contre LINQ car 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 les procs pour tout ce qui est réel.

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

B) Je ne suis pas convaincu que la modélisation d'objets soit de toute façon 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 de modifier, F5 et appuyez sur sélectionner et vous êtes parti pour les courses.

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

E) Linq to sql écrit toujours du code merdique à des moments où vous ne vous y attendez pas.

Honnêtement, je pense que l'ultime chose serait pour MS d'augmenter t-sql afin qu'il puisse faire une projection de jointure impliclitablement 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 procs stockés .... pwet-tu.

Il y a aussi le problème d'une possible restauration 2.0. Croyez-moi, cela m'est arrivé plusieurs fois, donc je suis sûr que cela est arrivé à d'autres.

Je conviens également que l'abstraction est la meilleure. Parallèlement au fait, le but initial d'un ORM est de faire en sorte que le SGBDR corresponde bien aux concepts OO. Cependant, si tout fonctionnait bien avant LINQ en ayant à dévier un peu des concepts OO, alors vissez-les. Les concepts et la réalité ne vont pas toujours bien ensemble. Il n'y a pas de place pour les fanatiques militants en informatique.

Je suppose que vous voulez dire Linq To Sql

Pour toute commande CRUD, il est facile de profiler les performances d'une procédure stockée par rapport à toute technologie. Dans ce cas, toute différence entre les deux sera négligeable. Essayez de profiler un objet de champ 5 (types simples) sur plus de 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 de placer votre logique métier sur votre base de données ou non, 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 partir pour un court voyage et n'avoir que de petits passagers (dans ce cas 2), optez pour LINQ avec élégance. Mais si vous voulez partir en voyage et avoir un large bande, je pense que vous devriez choisir SP.

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

J'espère que cela aide, je me trompe peut-être. :RÉ

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

Certains avantages ou Linq, je lis ici comme, facile à tester, facile à déboguer, etc., mais ils ne sont pas connectés à la sortie finale ou à l'utilisateur final. Cela va toujours causer des problèmes à l'utilisateur final sur les performances. Quel est le point de charger beaucoup de choses en mémoire, puis d'appliquer des filtres en utilisant LINQ?

Encore une fois, TypeSafety met en garde contre le fait que "nous veillons à éviter les erreurs de typage" qui, là encore, de mauvaise qualité, nous essayons d'améliorer en utilisant linq. Même dans ce cas, si quelque chose dans la base de données change, par exemple la taille de la colonne String, alors linq doit être recompilé et ne serait pas dactylographié sans cela .. J'ai essayé.

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

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

Pour les opérations CRUD simples avec un seul point d'accès aux données, je dirais 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 avez également l'aide de Tuning Advisor, SQL Server Profiler, pour le 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. Aussi 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 la procédure stockée, il est facile de tester sans toucher à l'application.

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

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

Sps: 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 leur place. Les deux ont leurs inconvénients et leurs avantages.

Parfois, pour la récupération de données complexes, vous pourriez avoir besoin de procs stockés. Et parfois, vous voudrez peut-être que d'autres personnes utilisent votre proc stocké dans Sql Server Management Studio.

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

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 besoins. Mais les procs stockés SQL ne disparaîtront pas de sitôt.