Saklı yordamlar vs LINQ-SQL? [kapalı]

StackOverflow ( LINQ için Yeni Başlayanlar Kılavuzu ) burada "LINQ için Başlangıç ​​Kılavuzu" yazısına bir göz attım , ancak bir takip sorum vardı:

Neredeyse tüm veritabanı operasyonlarımızın oldukça basit veri alımı olacağı yeni bir projeyi hızlandırmak üzereyiz (projenin zaten verileri yazan başka bir bölümü var). Bu noktaya kadar olan diğer projelerimizin çoğu, bu tür şeyler için saklı prosedürlerden yararlanmaktadır. Ancak, daha mantıklı ise LINQ-SQL kaldıraç istiyorum.

Yani, soru şudur: Basit veri alımı için hangi yaklaşım daha iyidir, LINQ-SQL veya depolanmış procs? Herhangi bir özel veya con?

Teşekkürler.

LINQ'nun sprokslara göre bazı avantajları:

1. Tip güvenliği : Sanırım hepimiz bunu anlıyoruz.
2. Soyutlama : Bu özellikle LINQ-to-Entities için geçerlidir . Bu soyutlama, çerçevenin kolayca yararlanabileceğiniz ek iyileştirmeler eklemesine de izin verir. PLINQ , LINQ'a çoklu iş parçacığı desteği ekleme örneğidir. Bu desteği eklemek için kod değişiklikleri minimum düzeydedir. Sprocları çağıran bu veri erişim kodunu yapmak çok daha zor olurdu.
3. Hata ayıklama desteği : Sorgularda hata ayıklamak için herhangi bir .NET hata ayıklayıcıyı kullanabilirim. Sprocs ile SQL'de kolayca hata ayıklayamazsınız ve bu deneyim veritabanı satıcınıza büyük ölçüde bağlıdır (MS SQL Server bir sorgu analizörü sağlar, ancak genellikle yeterli değildir).
4. Satıcı agnostik : LINQ çok sayıda veritabanıyla çalışır ve desteklenen veritabanı sayısı artar. Sprocs, değişken sözdizimi veya özellik desteği nedeniyle (veritabanı sprocs'u destekliyorsa) veritabanları arasında her zaman taşınabilir değildir.
5. Dağıtım : Diğerleri bundan daha önce bahsetti, ancak tek bir montajı dağıtmak bir dizi sprocs dağıtmaktan daha kolaydır. Bu aynı zamanda # 4 ile de bağlantılıdır.
6. Daha kolay : Veri erişimi yapmak için T-SQL'i veya sprocları çağırmak için gerekli olan veri erişim API'sını (örn. ADO.NET) öğrenmek zorunda değilsiniz. Bu, # 3 ve # 4 ile ilgilidir.

LINQ'nun sprocs'a karşı bazı dezavantajları:

1. Ağ trafiği : sprocs, yalnızca sproc-name ve argüman verilerini tel üzerinden serileştirirken LINQ tüm sorguyu gönderir. Sorgular çok karmaşıksa bu gerçekten kötü olabilir. Ancak, LINQ'nun soyutlaması Microsoft'un bunu zaman içinde geliştirmesini sağlar.
2. Daha az esnek : Sprocs bir veritabanının özellik kümesinden tam olarak yararlanabilir. LINQ, desteğinde daha genel olma eğilimindedir. Bu, her türlü dil soyutlamasında yaygındır (örn. C # ve birleştirici).
3. Yeniden derleme : Veri erişiminde değişiklik yapmanız gerekiyorsa, derlemenizi yeniden derlemeniz, sürümlendirmeniz ve yeniden konuşlandırmanız gerekir. Sprocs bazen bir DBA'nın herhangi bir şeyi yeniden konuşlandırmaya gerek kalmadan veri erişim rutinini ayarlamasına izin verebilir.

Güvenlik ve yönetilebilirlik, insanların da tartıştığı bir şeydir.

1. Güvenlik : Örneğin, doğrudan tablolara erişimi kısıtlayarak hassas verilerinizi koruyabilir ve spllara ACL'ler koyabilirsiniz. Bununla birlikte, LINQ ile, tablolara doğrudan erişimi kısıtlayabilir ve bunun yerine, benzer bir sonuç elde etmek için güncellenebilir tablo görünümlerine ACL'ler koyabilirsiniz (veritabanınızın güncellenebilir görünümleri desteklediği varsayılarak).
2. Yönetilebilirlik : Görünümlerin kullanılması, uygulamanızı şema değişikliklerinden (tablo normalizasyonu gibi) bozulmadan korumanıza da olanak tanır. Veri erişim kodunuzun değişmesine gerek kalmadan görünümü güncelleyebilirsiniz.

Eskiden büyük bir sproc adamıydım, ama genel olarak daha iyi bir alternatif olarak LINQ'ya doğru eğilmeye başlıyorum. Sproks'ların açıkça daha iyi olduğu bazı alanlar varsa, muhtemelen hala bir sproc yazacağım ama LINQ kullanarak erişeceğim. :)

Genelde, DBA'ların yıllardır üzerinde durduğu tüm nedenlerden ötürü, her şeyi saklı prosedürlere koymanın savunucusuyum. Linq durumunda, basit CRUD sorgularında performans farkı olmayacağı doğrudur.

Ancak bu kararı verirken birkaç şeyi aklınızda bulundurun: Herhangi bir ORM kullanmak veri modelinize sıkıca bağlanır. DBA'nın, derlenmiş kodunuzu değiştirmeye zorlamadan veri modelinde değişiklik yapma özgürlüğü yoktur. Saklı yordamlarda, bir yordamdan döndürülen parametre listesi ve sonuç kümeleri sözleşmesini temsil ettiğinden ve söz konusu sözleşme yine de yerine getirildiği sürece iç kısımlar değiştirilebildiğinden, bu tür değişiklikleri bir ölçüde gizleyebilirsiniz. .

Ayrıca, Linq daha karmaşık sorgular için kullanılıyorsa, veritabanını ayarlamak çok daha zor bir görev haline gelir. Saklı bir yordam yavaş çalıştığında, DBA tamamen ayrı bir şekilde koda odaklanabilir ve birçok seçenek vardır, böylece sözleşme tamamlandığında hala tatmin olur.

Bir uygulamada ciddi sorunların, dağıtılmış, derlenmiş kodda herhangi bir değişiklik yapılmadan saklı yordamlarda şema ve kod değişiklikleri ile giderildiği birçok, birçok durum gördüm.

Belki de bir hybird yaklaşımı Linq ile iyi olurdu? Linq, elbette, saklı prosedürleri çağırmak için kullanılabilir.

Linq - Sql.

Sql sunucusu sorgu planlarını önbelleğe alır, bu nedenle sprocs için performans kazancı yoktur.

Öte yandan, linq ifadeleriniz mantıksal olarak uygulamanızın bir parçası olacak ve test edilecektir. Sprocs her zaman biraz ayrılmıştır ve bakımı ve testi daha zordur.

Eğer şimdi sıfırdan yeni bir uygulama üzerinde çalışsaydım, sadece Linq, sprocs kullanmazdım.

Temel veri alımı için Linq için tereddüt etmeden gidiyorum.

Linq'e taşındığından beri aşağıdaki avantajları buldum:

1. DAL'ımda hata ayıklamak hiç bu kadar kolay olmamıştı.
2. Şemanız değiştiğinde zaman güvenliğini derleyin paha biçilmez.
3. Her şey DLL dosyalarına derlendiğinden dağıtım daha kolaydır. Artık dağıtım komut dosyalarını yönetmeye gerek yok.
4. Linq, IQueryable arabirimini uygulayan herhangi bir şeyi sorgulamayı destekleyebildiğinden, yeni bir sözdizimi öğrenmek zorunda kalmadan XML, Nesneler ve diğer veri kaynaklarını sorgulamak için aynı sözdizimini kullanabilirsiniz.

LINQ prosedür önbelleğini şişirir

Bir uygulama LINQ to SQL kullanıyorsa ve sorgular oldukça değişken uzunluğa sahip dizelerin kullanımını içeriyorsa, SQL Server yordam önbelleği olası her dize uzunluğu için sorgunun bir sürümü ile şişirilir. Örneğin, AdventureWorks2008 veritabanındaki Person.AddressTypes tablosunda oluşturulmuş aşağıdaki çok basit sorguları göz önünde bulundurun:

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;

Bu sorguların her ikisi de çalıştırılırsa, SQL Server yordam önbelleğinde iki girdi göreceğiz: Biri bir NVARCHAR (7), diğeri bir NVARCHAR (11) ile bağlı. Şimdi, hepsi farklı uzunluklarda olan yüzlerce veya binlerce farklı giriş dizesi olup olmadığını hayal edin. Yordam önbelleği, tam olarak aynı sorgu için her türlü farklı planla gereksiz yere doldurulacaktır.

Daha fazla bilgi için: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Pro LINQ argümanı, veritabanı geliştirme ile bir geçmişi olmayan insanlardan geliyor gibi görünüyor (genel olarak).

Özellikle VS DB Pro veya Team Suite gibi bir ürün kullanılıyorsa, burada yapılan argümanların çoğu geçerli değildir, örneğin:

Bakımı ve Testi Daha Zor: VS, tam sözdizimi denetimi, stil denetimi, başvuru ve kısıtlama denetimi ve daha fazlasını sağlar. Ayrıca, tam birim test yetenekleri ve yeniden düzenleme araçları sağlar.

LINQ, (aklımda) ACID testini geçemediğinden, gerçek birim testini imkansız hale getirir.

LINQ'da hata ayıklama daha kolaydır: Neden? VS yönetilen koddan tam adım atmayı ve SP'lerin düzenli hata ayıklamasını sağlar.

Dağıtım komut dosyaları yerine tek bir DLL dosyası olarak derlenir: VS, bir kez daha, tam veritabanları oluşturabileceği ve dağıtabileceği veya veri açısından güvenli artımlı değişiklikler yapabileceği kurtarmaya gelir.

LINQ ile TSQL öğrenmek zorunda değilsiniz: Hayır, ama LINQ öğrenmek zorundasınız - avantajı nerede?

Bunu gerçekten bir fayda olarak görmüyorum. Tek başına bir şeyi değiştirebilmek teoride iyi gelebilir, ancak değişikliklerin bir sözleşmeyi yerine getirmesi doğru sonuçları döndürdüğü anlamına gelmez. Doğru sonuçların ne olduğunu belirleyebilmek için içeriğe ihtiyacınız vardır ve bu içeriği arama kodundan alırsınız.

Gevşek bağlı uygulamalar, esnekliği gerçekten artırdıklarından tüm iyi programcıların nihai hedefidir. Bir şeyi izole olarak değiştirebilmek harika ve hala uygun sonuçları döndürmesini sağlayacak birim testleriniz.

Hepiniz üzülmeden önce, LINQ'nun yerini ve büyük bir geleceği olduğunu düşünüyorum. Ancak karmaşık, veri yoğun uygulamalar için saklı yordamların yerini almaya hazır olduğunu düşünmüyorum. Bu, TechEd'de bir MVP tarafından bu yıl yankıladığım bir görüştü (isimsiz kalacaklar).

EDIT: LINQ SQL saklı yordam tarafı şeylerin hala daha fazla okumak için gereken bir şey - ne bulduğuma bağlı olarak yukarıdaki diatribe değiştirebilir;)

LINQ yeni ve yerini aldı. LINQ saklı yordamı değiştirmek için icat edilmemiştir.

Burada bazı performans mitleri ve CONS, sadece "LINQ to SQL" için odaklanacağım, tabii ki tamamen yanlış olabilir ;-)

(1) İnsanlar LINQ ifadesinin SQL sunucusunda "önbellekleyebileceğini", dolayısıyla performansı kaybetmediğini söylüyor. Kısmen doğrudur. "LINQ to SQL" aslında çalışma zamanı LINQ sözdizimini TSQL ifadesine çevirir. Performans açısından sabit kodlanmış bir ADO.NET SQL deyiminin LINQ'dan farkı yoktur.

(2) Bir örnek verildiğinde, bir müşteri hizmetleri arayüzünün bir "hesap aktarımı" işlevi vardır. bu işlevin kendisi 10 DB tablosunu güncelleyebilir ve bazı mesajları tek seferde döndürebilir. LINQ ile, bir dizi ifade oluşturmanız ve bunları bir grup olarak SQL sunucusuna göndermeniz gerekir. bu çevrilmiş LINQ-> TSQL grubunun performansı saklı yordamla pek eşleşemez. Nedeni? Yerleşik SQL profiler ve yürütme planı aracını kullanarak Saklı yordamdaki ifadenin en küçük birimini düzenleyebileceğiniz için, bunu LINQ'da yapamazsınız.

Mesele şu ki, tek DB tablosu ve küçük veri kümesi CRUD söz konusu olduğunda, LINQ SP kadar hızlıdır. Ancak çok daha karmaşık bir mantık için, saklı yordam daha fazla performans tweakable.

(3) "LINQ to SQL" kolayca performans domuzlarını tanıtmak için yeni başlayanlar yapar. Herhangi bir üst düzey TSQL üyesi CURSOR'u ne zaman kullanmayacağınızı söyleyebilir (Temelde CURSOR'u çoğu durumda TSQL'de kullanmamalısınız). LINQ ve sorgu ile büyüleyici "foreach" döngü ile, bir acemi için böyle bir kod yazmak çok kolay:

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

Bu kolay iyi kodun çok çekici olduğunu görebilirsiniz. Ancak başlık altında, .NET çalışma zamanı bunu bir güncelleme toplu işlemine çevirir. Sadece 500 satır varsa, bu 500 satır TSQL toplu işidir; Milyon hat varsa, bu bir hit. Tabii ki, deneyimli kullanıcı bu işi yapmak için bu yolu kullanmayacak, ama asıl nokta, bu şekilde düşmek çok kolay.

En iyi kod kod değildir ve saklı yordamlar için, veritabanında en az bir kod ve onu çağırmak için uygulamada kod yazmanız gerekirken, LINQ to SQL veya LINQ to Entities ile herhangi bir ek yazmak zorunda kalmazsınız. bir bağlam nesnesinin somutlaştırılması dışında, diğer herhangi bir LINQ sorgusunun ötesinde kodlama.

LINQ kesinlikle uygulamaya özel veritabanlarında ve küçük işletmelerde yerini alır.

Ancak, merkezi veritabanlarının birçok uygulama için ortak veri merkezi olarak hizmet ettiği büyük bir kuruluşta soyutlamaya ihtiyacımız var. Güvenliği merkezi olarak yönetmeli ve erişim geçmişlerini göstermeliyiz. Etki analizi yapabilmeliyiz: yeni bir işletme ihtiyacını karşılamak için veri modelinde küçük bir değişiklik yaparsam, hangi sorguların değiştirilmesi ve hangi uygulamaların yeniden test edilmesi gerekir? Görüşler ve Saklı Yordamlar bunu bana verir. LINQ tüm bunları yapabilirse ve programcılarımızı daha üretken hale getirirse, memnuniyetle karşılarım - bu tür bir ortamda kullanma deneyimi olan var mı?

DBA'nın, derlenmiş kodunuzu değiştirmeye zorlamadan veri modelinde değişiklik yapma özgürlüğü yoktur. Saklı yordamlarda, bir yordamdan döndürülen parametre listesi ve sonuç kümeleri sözleşmesini temsil ettiğinden ve söz konusu sözleşme yine de yerine getirildiği sürece iç kısımlar değiştirilebildiğinden, bu tür değişiklikleri bir ölçüde gizleyebilirsiniz. .

Bunu gerçekten bir fayda olarak görmüyorum. Tek başına bir şeyi değiştirebilmek teoride iyi gelebilir, ancak değişikliklerin bir sözleşmeyi yerine getirmesi doğru sonuçları döndürdüğü anlamına gelmez. Doğru sonuçların ne olduğunu belirleyebilmek için içeriğe ihtiyacınız vardır ve bu içeriği arama kodundan alırsınız.

IMHO, RAD = LINQ, RUP = Depolanmış Procs. Büyük bir Fortune 500 şirketinde uzun yıllar boyunca, yönetim de dahil olmak üzere birçok seviyede çalıştım ve açıkçası, RUP geliştiricilerini RAD geliştirme yapmak için asla işe almam. O kadar aptallar ki, sürecin diğer seviyelerinde ne yapılacağı hakkında çok sınırlı bilgiye sahipler. Sessiz bir ortamla, DBA'lara çok spesifik giriş noktaları aracılığıyla veriler üzerinde kontrol vermek mantıklıdır, çünkü diğerleri açıkçası veri yönetimini başarmanın en iyi yollarını bilmez.

Ancak büyük işletmeler , geliştirme alanında acı verici bir şekilde yavaş hareket ediyor ve bu son derece maliyetli. Hem zamandan hem de paradan tasarruf etmek için daha hızlı hareket etmeniz gereken zamanlar vardır ve LINQ bunu ve daha fazlasını maça sağlar.

Bazen DBA'ların LINQ'ya karşı önyargılı olduğunu düşünüyorum çünkü iş güvenliğini tehdit ettiğini düşünüyorlar. Ama bu canavarın doğası, bayanlar ve baylar.

Bence gerçek bir şey için procs ile gitmelisin.

A) Tüm mantığınızı linq olarak yazmak, veritabanınızın daha az kullanışlı olduğu anlamına gelir, çünkü yalnızca uygulamanız onu tüketebilir.

B) Nesne modellemenin yine de ilişkisel modellemeden daha iyi olduğuna ikna olmadım.

C) SQL'de saklı bir yordamı sınamak ve geliştirmek, herhangi bir Visual Studio ortamında derleme düzenleme döngüsüne göre çok daha hızlıdır. Sadece düzenleyin, F5 ve select'e basın ve yarışlara gidersiniz.

D) Saklı yordamları yönetmek ve dağıtmak montajlardan daha kolaydır .. sadece dosyayı sunucuya koyun ve F5'e basın ...

E) Linq to sql hala beklemediğiniz zaman berbat kod yazıyor.

Dürüst olmak gerekirse, ben MS için t-sql artırmak için nihai şey olacağını düşünüyorum, böylece linq yaptığı gibi bir birleşim projeksiyon impliclitly yapabilirsiniz. t-sql, örneğin order.lineitems.part yapmak isteyip istemediğinizi bilmelidir.

LINQ, saklı yordamların kullanılmasını yasaklamaz. LINQ-SQL ve LINQ-depolanmış proc ile karışık mod kullandım . Şahsen, saklanan procs yazmak zorunda değilim sevindim .... pwet-tu.

Ayrıca, olası 2.0 geri alma sorunu da vardır. Bana güvenin bana birkaç kez oldu, bu yüzden eminim başkalarına da oldu.

Aynı zamanda soyutlamanın en iyisi olduğuna katılıyorum. Gerçekle birlikte, bir ORM'nin asıl amacı RDBMS'nin OO kavramlarıyla uyumlu olmasını sağlamaktır. Ancak, her şey LINQ'dan önce OO konseptlerinden biraz sapmak zorunda kaldığında işe yaradıysa, vidalayın. Kavramlar ve gerçeklik her zaman birbirine uymaz. BT'de militan zeklotlara yer yok.

Linq To Sql demek istediğini varsayıyorum

Herhangi bir CRUD komutu için, saklı bir yordamın performansı ile herhangi bir teknolojinin karşılaştırılması kolaydır. Bu durumda, ikisi arasındaki herhangi bir fark göz ardı edilebilir olacaktır. Gerçek bir fark olup olmadığını öğrenmek için 100.000'den fazla seçme sorgusu için 5 (basit türler) alan nesnesinin profilini oluşturmayı deneyin.

Öte yandan, gerçek anlaşma kırıcı iş mantığınızı veritabanınıza koymak ya da değil, bu saklı yordamlara karşı bir argüman koyarak rahat olup olmadığı sorusu olacaktır.

Gurulara göre, LINQ'yu motosiklet ve SP'yi araba olarak tanımlıyorum. Kısa bir yolculuğa çıkmak ve sadece küçük yolcularınız varsa (bu durumda 2), LINQ ile incelikle gidin. Ama bir yolculuğa çıkmak ve büyük bir gruba sahip olmak istiyorsanız, bence SP'yi seçmelisiniz.

Sonuç olarak, motosiklet veya araba arasında seçim yapmak rotanıza (iş), uzunluğa (zaman) ve yolculara (verilere) bağlıdır.

Umarım yardımcı olur, yanlış olabilirim. : D

LINQ'ya yönelik tüm bu cevaplar, esas olarak, az ya da çok kodlama kalitesinin düşük olması ya da kodlamadaki tembellik ile bağlantılı olan KALKINMA KOLAYLIĞI'ndan bahsetmektedir. Ben sadece böyleyim.

Bazı avantajlar veya Linq, burada, test edilmesi kolay, hata ayıklaması kolay vb. Olarak okudum, ancak bunlar nihai çıktıya veya son kullanıcıya bağlı değil. Bu her zaman son kullanıcının performans sorununa neden oluyor. Ne bellekte birçok şey yükleme ve daha sonra LINQ kullanarak filtreler uygulamak nedir?

Yine TypeSafety, linq kullanarak tekrar geliştirmeye çalıştığımız "yanlış tiplemeden kaçınmaya dikkat ediyoruz". Bu durumda bile, veritabanındaki herhangi bir şey değiştiğinde, örneğin Dize sütununun boyutu değiştiğinde, linq yeniden derlenmelidir ve bu olmadan typesafe olmazdı .. Denedim.

Her ne kadar, LINQ ile çalışırken iyi, tatlı, ilginç vb.

Tembel olmayı bırak. Çok çalışıyorum. :)

Tek bir veri erişim noktasına sahip basit CRUD işlemleri için sözdiziminden memnun kalırsanız LINQ için gidin diyebilirim. Daha karmaşık mantık için, eğer T-SQL ve daha gelişmiş işlemlerinde iyiyseniz, sproksların daha verimli performans olduğunu düşünüyorum. Ayrıca Tuning Advisor, SQL Server Profiler, sorgularınızı SSMS'den hata ayıklama vb.

Saklı yordam testi kolaylaştırır ve uygulama koduna dokunmadan sorguyu değiştirebilirsiniz. Ayrıca linq ile veri almak, doğru veri olduğu anlamına gelmez. Verilerin doğruluğunu test etmek, uygulamayı çalıştırmak anlamına gelir, ancak saklı yordamla uygulamaya dokunmadan test etmek kolaydır.

Sonuç şu şekilde özetlenebilir:

Küçük siteler ve prototipler için LinqToSql. Prototipleme için gerçekten zaman kazandırır.

Sps: Evrensel. Sorgularıma ince ayar yapabilir ve her zaman ActualExecutionPlan / EstimatedExecutionPlan'ı kontrol edebilirim.

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

Hem LINQ hem de SQL'in yerleri vardır. Her ikisinin dezavantajları ve avantajları vardır.

Bazen karmaşık veri alımı için kaydedilmiş prokslara ihtiyacınız olabilir. Ve bazen başkalarının Sql Server Management Studio'da depolanmış proc'nuzu kullanmasını isteyebilirsiniz.

Linq to Entities, hızlı CRUD gelişimi için mükemmeldir.

Tabii sadece birini veya diğerini kullanarak bir uygulama oluşturabilirsiniz. Veya karıştırabilirsiniz. Her şey gereksinimlerinize geliyor. Ancak SQL'de saklanan procs yakında hiçbir zaman kaybolmayacak.