LINQ إلى SQL مقابل تخزين الإجراءات ؟ [مغلقة]

https://stackoverflow.com/questions/14530

08-06-2019
|

سؤال

أخذت نظرة على "دليل المبتدئين إلى LINQ" نشر هنا على ستاكوفيرفلوو (دليل المبتدئين إلى LINQ) ، ولكن كان متابعة السؤال:

نحن على وشك رفع مشروع جديد حيث ما يقرب من جميع من قاعدة البيانات لدينا op سوف تكون بسيطة إلى حد كبير بيانات الاسترجاع (هناك جزء آخر من المشروع الذي يكتب البيانات).معظم مشاريع أخرى تصل إلى هذه النقطة تجعل استخدام الإجراءات المخزنة عن مثل هذه الأمور.ومع ذلك أود أن النفوذ LINQ إلى SQL إذا كان أكثر منطقية.

إذن السؤال هو:بسيطة بيانات الاسترجاع ، وهو النهج هو أفضل ، LINQ إلى SQL أو تخزينها procs?أي محددة برو أو يخدع ؟

شكرا

المحلول

بعض مزايا ينق على sprocs:

نوع السلامة:أعتقد أننا جميعا ندرك هذا.
التجريد:وهذا ينطبق بشكل خاص مع LINQ إلى كيانات.هذا التجريد كما يسمح إطار لإضافة المزيد من التحسينات التي يمكنك بسهولة الاستفادة من. PLINQ مثال على إضافة دعم متعدد خيوط إلى LINQ.رمز التغييرات هي الحد الأدنى لإضافة هذا الدعم.سيكون أصعب بكثير أن تفعل هذه البيانات رمز الوصول ببساطة المكالمات sprocs.
دعم التصحيح:يمكنني استخدام أي .الصافي المصحح تصحيح الاستعلامات.مع sprocs لا يمكنك بسهولة تصحيح SQL وأن التجربة إلى حد كبير مرتبطة إلى قاعدة البيانات الخاصة بك بائع (MS SQL Server يوفر استعلام محلل, ولكن في كثير من الأحيان هذا لا يكفي).
بائع الملحد:LINQ يعمل مع الكثير من قواعد البيانات عدد قواعد البيانات المعتمدة سوف تزيد فقط.Sprocs ليست دائما المحمولة بين قواعد البيانات ، إما بسبب متفاوتة بناء الجملة أو دعم ميزة (إذا كانت قاعدة البيانات يدعم sprocs على الإطلاق).
نشر:الآخرين قد ذكر هذا بالفعل, ولكن من الأسهل لنشر واحد الجمعية من نشر مجموعة من sprocs.هذا أيضا في العلاقات مع #4.
أسهل:لم يكن لديك لمعرفة T-SQL للقيام الوصول إلى البيانات ، ولا عليك أن تتعلم الوصول إلى البيانات API (مثلا ، ADO.NET) من الضروري استدعاء sprocs.هذا هو ذات الصلة إلى #3 و #4.

بعض مساوئ LINQ مقابل sprocs:

حركة مرور شبكة الاتصال:sprocs تحتاج فقط تسلسل sproc-اسم الحجة البيانات عبر السلك في حين LINQ يرسل كامل الاستعلام.هذا يمكن أن تسوء إذا استعلامات معقدة جدا.ومع ذلك ، ينق التجريد يسمح Microsoft لتحسين هذا مع مرور الوقت.
أقل مرونة:Sprocs يمكن الاستفادة الكاملة من قاعدة البيانات featureset.LINQ يميل إلى أن يكون أكثر عمومية في الدعم.وهذا أمر شائع في أي نوع من لغة التجريد (مثلا ، C# مقابل المجمع).
ترجمة:إذا كنت تحتاج إلى إجراء تغييرات على الطريقة التي لديك الوصول إلى البيانات, تحتاج إلى إعادة ترجمة, الإصدار, نقل التجميع الخاص بك.Sprocs يمكن في بعض الأحيان تسمح ديسيبل لضبط الوصول إلى البيانات الروتينية من دون الحاجة إلى نقل أي شيء.

الأمن والإدارة هي شيء أن الناس يقولون عنه أيضا.

الأمن:على سبيل المثال ، يمكنك حماية البيانات الحساسة الخاصة بك عن طريق تقييد الوصول إلى الجداول مباشرة ، ووضع قوائم Acl على sprocs.مع LINQ, ومع ذلك, لا يزال يمكنك تقييد الوصول المباشر إلى الجداول و بدلا من ذلك وضع ACLs على طاولة قابلة للتحديث الآراء لتحقيق مماثلة نهاية (على افتراض قاعدة البيانات الخاصة بك يدعم وجهات نظر قابلة للتحديث).
الإدارة:وذلك باستخدام وجهات النظر يتيح لك أيضا بحجب التطبيق الخاص بك غير كسر من التغييرات المخطط (مثل الجدول التطبيع).يمكنك تحديث عرض دون الحاجة إلى البيانات الخاصة بك رمز الوصول إلى التغيير.

اعتدت أن تكون كبيرة sproc الرجل ولكن أنا بدأت تميل نحو LINQ كبديل أفضل بشكل عام.إذا كان هناك بعض المناطق حيث sprocs هي أفضل بوضوح ، ثم ربما لا تزال كتابة sproc ولكن الوصول إليه باستخدام LINQ.:)

نصائح أخرى

أنا عموما يفضل وضع كل شيء في الإجراءات المخزنة لجميع الأسباب دباس قد تم تعزف لسنوات.في حالة Linq, صحيح أنه لن يكون هناك أداء الفرق بسيط الخام الاستعلامات.

ولكن يبقى عدد قليل من الأشياء في الاعتبار عند اتخاذ هذا القرار:باستخدام أي ORM الأزواج كنت بإحكام إلى نموذج البيانات.ديسيبل ليس له الحرية في إجراء تغييرات على نموذج البيانات دون أن يجبرك على تغيير التعليمات البرمجية المترجمة.مع الإجراءات المخزنة يمكنك إخفاء هذه الأنواع من التغييرات إلى حد ما ، منذ المعلمة قائمة النتائج(s) عاد من الإجراءات تمثل العقد أحشاء يمكن أن يتغير من حولها ، طالما أن العقد لا يزال التقى.

و أيضا إذا Linq يستخدم لمزيد من الاستعلامات المعقدة ، ضبط قاعدة البيانات يصبح مهمة أكثر صعوبة بكثير.عند إجراء مخزن يعمل ببطء ، ديسيبل يمكن أن تركز كليا على رمز في عزلة, و لديها الكثير من الخيارات ، ذلك أن العقد لا يزال راضيا عندما قال انه/انها فعلت.

لقد رأيت العديد والعديد من الحالات التي يكون فيها مشاكل خطيرة في تطبيق ما تم تناولها من قبل تغييرات على المخطط و رمز في الإجراءات المخزنة دون أي تغيير إلى نشر التعليمات البرمجية المترجمة.

ربما هاي برد النهج من شأنه أن يكون لطيفا مع Linq?Linq يمكن بالطبع أن تستخدم استدعاء الإجراءات المخزنة.

Linq to Sql.

Sql server سيتم التخزين المؤقت الاستعلام خطط لذلك لا يوجد كسب الأداء بالنسبة sprocs.

الخاص بك linq البيانات ، من ناحية أخرى ، سيكون منطقيا جزء من واختبارها مع التطبيق الخاص بك.Sprocs دائما قليلا فصل أكثر صعوبة للحفاظ على الاختبار.

إذا كنت تعمل على تطبيق جديد من الصفر الآن أنا فقط استخدام Linq لا sprocs.

الأساسية استرجاع البيانات سوف يكون الذهاب Linq دون تردد.

منذ انتقاله إلى Linq لقد وجدت المزايا التالية:

التصحيح بلدي الدال لم تكن أسهل.
وقت الترجمة السلامة عند التغييرات المخطط لا تقدر بثمن.
نشر أسهل لأن كل شيء يتم تجميعها في DLL.لا مزيد من إدارة نشر النصوص.
لأن Linq يمكن أن تدعم الاستعلام عن أي شيء التي تطبق IQueryable واجهة, سوف تكون قادرة على استخدام نفس جملة الاستعلام XML, الكائنات وغيرها من البيانات دون الحاجة إلى تعلم جديد بناء الجملة

LINQ سوف تشعر بالانتفاخ ذاكرة التخزين المؤقت الإجراء

إذا كان تطبيق باستخدام LINQ to SQL و الاستفسارات تنطوي على استخدام السلاسل التي يمكن أن يكون متغير بدرجة كبيرة في طول SQL Server ذاكرة التخزين المؤقت الإجراء سوف تصبح منتفخة مع نسخة واحدة من الاستعلام عن كل طول السلسلة.على سبيل المثال ، يجب مراعاة ما يلي بسيطة جدا الاستفسارات التي تم إنشاؤها ضد الشخص.AddressTypes الجدول في 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;

إذا كان كل من هذه الأسئلة تشغيل, سوف نرى اثنين إدخالات في SQL Server ذاكرة التخزين المؤقت الإجراء:واحدة ملزمة مع NVARCHAR(7) ، و أخرى مع NVARCHAR(11).الآن تخيل لو كان هناك المئات أو الآلاف من مختلف المدخلات سلاسل, كل مع أطوال مختلفة.ذاكرة التخزين المؤقت الإجراء سوف تصبح بلا داع مليئة بكل أنواع مختلفة من خطط نفس الاستعلام.

أعتقد برو LINQ الحجة يبدو أن تأتي من الناس الذين ليس لديهم تاريخ مع تطوير قاعدة البيانات (في العام).

وخاصة في حالة استخدام منتج مثل مباراة DB برو أو فريق جناح العديد من الحجج المقدمة هنا لا تنطبق على سبيل المثال:

من الصعب الحفاظ على الاختبار:مقابل توفر كامل تدقيق لغوي, أسلوب التدقيق ، المرجعي و القيد التحقق وأكثر من ذلك.كما توفر وحدة اختبار قدرات و تقسيم الأدوات.

LINQ يجعل صحيح اختبار وحدة المستحيل (في رأيي) أنه فشل في الاختبار.

التصحيح أسهل في LINQ:لماذا ؟ مقابل تسمح كامل خطوة من التعليمات البرمجية المدارة و التصحيح العادي من الصحة والصحة النباتية.

جمعت في واحد DLL بدلا من نشر النصوص:مرة أخرى مقابل يأتي إلى الإنقاذ حيث يمكن بناء ونشر الكامل في قواعد البيانات أو تقديم بيانات آمنة تغييرات تدريجية.

لا يجب أن تعلم tsql ضمن مع LINQ:لا لا, ولكن عليك أن تعلم LINQ - أين الفائدة ؟

أنا حقا لا أرى هذا يجري فائدة.كونها قادرة على تغيير شيء في عزلة قد يبدو جيدا من الناحية النظرية ، ولكن فقط لأن التغييرات الوفاء العقد لا يعني انها تعود النتائج الصحيحة.أن تكون قادرة على تحديد ما النتائج الصحيحة هي تحتاج السياق يمكنك الحصول على هذا السياق من استدعاء التعليمات البرمجية.

أم ، المتباعدة التطبيقات هي الهدف النهائي من جميع المبرمجين جيد كما أنهم حقا لا زيادة المرونة.كونها قادرة على تغيير الأمور في عزلة رائعة ، وهو وحدة الاختبارات لضمان أنها لا تزال العودة النتائج المناسبة.

قبل كل ينزعج أعتقد ينق له مكانه وله مستقبل كبير.ولكن كثيفة البيانات المعقدة التطبيقات أنا لا أعتقد أنه هو على استعداد لاتخاذ مكان الإجراءات المخزنة.كان هذا رأي أنا رددت من قبل MVP في مختل عقليا هذا العام (سوف يظل الاسم).

تحرير:على LINQ to SQL الإجراء المخزن الجانب من الأشياء هو شيء أنا لا تزال بحاجة إلى قراءة أكثر على حسب ما وجدت أنا قد يغير فوق الكلام ;)

LINQ جديدة لها مكان.LINQ ليس اخترع استبدال الإجراء المخزن.

هنا سوف نركز على بعض الأداء الأساطير & سلبيات فقط "LINQ to SQL" ، بالطبع قد تكون خاطئة تماما ;-)

(1)يقول الناس LINQ المنصورة أن "ذاكرة التخزين المؤقت" في SQL server, حتى لا تفقد الأداء.صحيح جزئيا."LINQ to SQL" في الواقع هو وقت التشغيل ترجمة LINQ بناء الجملة tsql ضمن المنصورة.حتى من وجهة نظر الأداء ، الثابت ترميز ADO.NET SQL قد لا فرق من LINQ.

(2)إعطاء مثال خدمة العملاء واجهة المستخدم لديه حساب "نقل" وظيفة.هذه الوظيفة نفسها قد تحديث 10 ديسيبل الجداول و عودة بعض الرسائل في طلقة واحدة.مع LINQ لديك لبناء مجموعة من البيانات وإرسالها دفعة واحدة إلى SQL server.أداء هذه ترجمة LINQ->tsql ضمن دفعة بالكاد مباراة الإجراء المخزن.سبب ؟ لأنه يمكنك قرص أصغر وحدة من البيان في تخزين procedue باستخدام المدمج في منشئ ملفات التعريف SQL وتنفيذ خطة أداة, أنت لا تستطيع أن تفعل هذا في LINQ.

المهم هو عندما نتحدث واحد DB الجدول و مجموعة صغيرة من البيانات الخام ، LINQ بأسرع SP.ولكن أكثر تعقيدا بكثير المنطق, تخزين الإجراء هو أكثر من الأداء tweakable.

(3)"LINQ to SQL" بسهولة يجعل نوبي لتقديم أداء الخنازير.أي كبار tsql ضمن الرجل يمكن أن أقول لكم عندما لا تستخدم المؤشر (الأساس يجب عدم استخدام المؤشر في tsql ضمن في معظم الحالات).مع LINQ و الساحرة "foreach" حلقة مع الاستعلام, أنه من السهل جدا بالنسبة للمبتدئ أن أكتب هذه المدونة:

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

يمكنك ان ترى هذا من السهل الكريم رمز جذابة جدا.ولكن تحت غطاء محرك السيارة .NET runtime فقط ترجمة هذا التحديث دفعة واحدة.إذا كان هناك فقط 500 خطوط ، وهذا هو 500 خط tsql ضمن الدفعة ؛ إذا كان هناك مليون خط ، هذا هو ضرب.بالطبع خبرة المستخدم لن تستخدم هذه الطريقة للقيام بهذه المهمة, ولكن النقطة هي أنه من السهل جدا أن تقع في هذا الطريق.

أفضل مدونة مدونة ، مع الإجراءات المخزنة لديك لكتابة على الأقل بعض التعليمات البرمجية في قاعدة البيانات و التعليمات البرمجية في التطبيق أن نسميها ، بينما مع LINQ to SQL أو LINQ إلى كيانات لم يكن لديك لكتابة أي رمز إضافية أبعد من أي استعلام LINQ جانبا من إنشاء مثيل كائن سياق.

LINQ بالتأكيد له مكانه في التطبيق محددة وقواعد البيانات في الشركات الصغيرة.

ولكن في مؤسسة كبيرة ، حيث قواعد البيانات المركزية بمثابة محور البيانات المشتركة للعديد من التطبيقات ، نحن بحاجة إلى التجريد.نحن بحاجة إلى إدارة مركزية الأمن وإظهار الوصول وتاريخها.نحن بحاجة إلى أن تكون قادرة على القيام تحليل الأثر:إن إجراء تغيير صغير إلى نموذج البيانات لخدمة الأعمال الجديدة تحتاج ما استفسارات بحاجة إلى تغيير و ما التطبيقات التي تحتاج إلى إعادة اختبار ؟ آراء و الإجراءات المخزنة أعطني ذلك.إذا LINQ يمكن أن تفعل كل ذلك جعل المبرمجين لدينا أكثر إنتاجية ، سوف نرحب به -- هل من أحد لديه الخبرة في استخدامه في هذا النوع من البيئة ؟

ديسيبل ليس له الحرية في إجراء تغييرات إلى نموذج البيانات دون إجبار لك تغيير التعليمات البرمجية المترجمة.مع الإجراءات المخزنة يمكنك إخفاء هذه أنواع التغييرات إلى حد ما ، منذ المعلمة قائمة النتائج(s) عاد من الإجراءات تمثل العقد ، و أحشاء يمكن تغيرت حولها ، طالما أن العقد لا يزال التقى.

أنا حقا لا أرى هذا يجري فائدة.كونها قادرة على تغيير شيء في عزلة قد يبدو جيدا من الناحية النظرية ، ولكن فقط لأن التغييرات الوفاء العقد لا يعني انها تعود النتائج الصحيحة.أن تكون قادرة على تحديد ما النتائج الصحيحة هي تحتاج السياق يمكنك الحصول على هذا السياق من استدعاء التعليمات البرمجية.

IMHO راد = LINQ RUP = المخزنة Procs.عملت كبيرة فورتشن 500 شركة لسنوات عديدة في العديد من المستويات بما في ذلك إدارة و بصراحة أنا لن تأجير RUP المطورين للقيام راد التنمية.وهم بذلك siled أنها محدودة جدا معرفة ما يجب القيام به في مستويات أخرى من هذه العملية.مع siled البيئة ، فمن المنطقي أن تعطي دباس التحكم في البيانات عن طريق محددة جدا من نقاط الدخول ، لأن الآخرين بصراحة لا أعرف أفضل السبل لتحقيق إدارة البيانات.

ولكن الشركات الكبيرة تتحرك مؤلم بطيئة في مجال التنمية ، وهذا هو مكلفة للغاية.هناك أوقات عندما تحتاج إلى نقل أسرع إلى توفير الوقت والمال ، LINQ يوفر هذا وأكثر في البستوني.

في بعض الأحيان أعتقد أن دباس هي منحازة ضد LINQ لأنهم يشعرون أنه يهدد أمنهم الوظيفي.ولكن هذه هي طبيعة الوحش ، أيها السيدات والسادة.

أعتقد أن عليك أن تذهب مع procs عن أي شيء حقيقي.

أ) كتابة كل ما تبذلونه من المنطق في linq يعني قاعدة البيانات الخاصة بك هو أقل فائدة فقط لأن التطبيق الخاص بك يمكن أن تستهلك.

ب) أنا غير مقتنع بأن الكائن النمذجة هو أفضل من النماذج العلائقية على أي حال.

ج) اختبار وتطوير إجراء مخزن في SQL الكثير أسرع من تجميع تحرير دورة في أي Visual Studio البيئة.يمكنك فقط تحرير F5 وضرب حدد وأنت خارج السباقات.

د) أنه من الأسهل لإدارة ونشر الإجراءات المخزنة من الجمعيات..عليك فقط وضع الملف على الخادم ، ثم اضغط على F5...

هـ) Linq to sql لا يزال يكتب في الاستراحة في أوقات عندما كنت لا تتوقع ذلك.

بصراحة أعتقد شيء في نهاية المطاف سيكون MS لزيادة t-sql بحيث يمكن أن تفعل الانضمام إلى إسقاط impliclitly الطريق linq لا.t-sql يجب أن تعرف إذا كنت تريد أن تفعل النظام.lineitems.جزء منه ، على سبيل المثال.

LINQ لا تحظر استخدام الإجراءات المخزنة.لقد استعملت وضع مختلطة مع LINQ-SQL ، LINQ-storedproc.شخصيا, أنا سعيد لأنني لم يكن لديك لكتابة المخزنة procs....pwet-تو.

أيضا هناك مسألة من الممكن 2.0 التراجع.ثق بي لقد حدث لي عدة مرات لذلك أنا متأكد من أنه قد حدث الآخرين.

كما توافق على أن التجريد هو أفضل.جنبا إلى جنب مع الواقع ، فإن الغرض الأصلي من ORM هو جعل RDBMS متابعة المباراة بشكل جيد إلى OO المفاهيم.ومع ذلك ، إذا كان كل شيء يعمل على ما يرام قبل LINQ قبل الاضطرار إلى الخروج قليلا من OO المفاهيم ثم تبا لهم.المفاهيم و الواقع دائما لا تناسب معا بشكل جيد.لا يوجد مجال المتشددين المتعصبين في ذلك.

أفترض أنك تعني Linq To Sql

أي CRUD الأمر من السهل تعريف أداء الإجراء المخزن مقابلأي تكنولوجيا.في هذه الحالة أي فرق بين الاثنين ستكون ضئيلة.محاولة التنميط لمدة 5 (الأنواع البسيطة) حقل كائن أكثر من 100 ، 000 استعلامات التحديد لمعرفة ما إذا كان هناك فرق حقيقي.

من ناحية أخرى الصفقة الحقيقية الكسارة سوف تكون السؤال على ما إذا كنت تشعر بالراحة وضع منطق تسلسل العمل الخاص بك على قاعدة البيانات الخاصة بك أم لا ، الذي هو حجة ضد الإجراءات المخزنة.

وفقا معلمو ، تعريف LINQ كما نارية و SP السيارات.إذا كنت تريد أن تذهب في رحلة قصيرة فقط صغيرة الركاب(في هذه الحالة 2) ، انتقل بأمان مع LINQ.ولكن إذا كنت تريد أن تذهب في رحلة قد فرقة كبيرة, أعتقد أن عليك أن تختار SP.

وختاما, اختيار بين دراجة نارية أو سيارة تعتمد على المسار الخاص بك (رجال الأعمال) ، طول (الوقت) و الركاب (البيانات).

آمل أن يساعد ، قد تكون خاطئة.:D

كل هذه الإجابات يميل نحو LINQ نتحدث أساسا عن سهولة التطوير والتي هي أكثر أو أقل متصل إلى سوء نوعية الترميز أو الكسل في الترميز.أنا هكذا فقط.

بعض المزايا أو ينق قرأت هنا , من السهل اختبار سهل التصحيح الخ ، ولكن هذه لا يوجد فيها اتصال الناتج النهائي أو المستخدم النهائي.هذا هو دائما ما يسبب مشاكل للمستخدم النهائي على الأداء.ما وجهة تحميل العديد من الأشياء في الذاكرة ومن ثم تطبيق المرشحات على استخدام LINQ?

مرة أخرى TypeSafety هو الحذر "نحن حريصون على تجنب الخطأ تلبيس" مرة أخرى نوعية رديئة نحن نحاول تحسين باستخدام linq.حتى في هذه الحالة ، إذا كان أي شيء في التغييرات على قاعدة البيانات, على سبيل المثالحجم سلسلة العمود ، ثم ينق يحتاج إلى إعادة تجميع لن يكون typesafe دون ذلك ..لقد حاولت.

على الرغم من أننا وجدنا جيد, الحلو, مثيرة للاهتمام الخ بينما كان يعمل مع LINQ ، فقد القص العيب من صنع المطور كسول :) وثبت 1000 مرة سيئة (قد يكون أسوأ) على الأداء مقارنة المخزنة Procs.

التوقف عن كونه كسول.أحاول من الصعب.:)

تخزين Procs مقابل رمز (المناقشة السابقة)

بسيطة عمليات الخام مع واحد الوصول إلى البيانات النقطة ، أود أن أقول تذهب LINQ إذا كنت تشعر بالراحة مع بناء الجملة.لمزيد من التعقيد المنطق أعتقد sprocs أكثر efficiant الحكمة إذا كنت جيدة في T-SQL و أكثر تقدما العمليات.لديك أيضا مساعدة من ضبط مستشار SQL Server منشئ ملفات التعريف التصحيح الاستفسارات الخاصة بك من صواريخ أرض-أرض.... الخ

الإجراء المخزن يجعل اختبار أسهل و يمكنك تغيير الاستعلام دون لمس التعليمات البرمجية للتطبيق.أيضا مع linq, الحصول على البيانات لا يعني البيانات الصحيحة.واختبار صحة البيانات يعني تشغيل التطبيق ولكن مع الإجراء المخزن فإنه من السهل أن الاختبار دون لمس التطبيق.

نتائج يمكن تلخيصها على النحو

LinqToSql على المواقع الصغيرة و النماذج.حقا يوفر الوقت النماذج.

Sps :العالمي.أنا يمكن تهذيب الاستفسارات بلدي و دائما التحقق من 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 و SQL قد أماكنهم.على حد سواء لديها عيوب ومزايا.

في بعض الأحيان معقدة استرجاع البيانات قد تحتاج إلى تخزين procs.و في بعض الأحيان قد تريد الآخرين أن استخدام proc المخزنة في Sql Server إدارة Studio.

Linq إلى كيانات كبيرة لسرعة الخام التنمية.

متأكد من أنك يمكن بناء التطبيق فقط باستخدام واحدة أو أخرى.أو يمكنك مزجها.كل ذلك يأتي نزولا إلى الاحتياجات الخاصة بك.ولكن SQL المخزنة procs سوف لا يذهب بعيدا في أي وقت قريب.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow