Birinin Dinamik SQL kullanmak istemediğini söylediğini duydum. Somut bir örnek veya gerçek hayat örneği verebilir misiniz? Şahsen, veritabanımda birkaç kez kodluyorum. Bence sorun yok çünkü esneklik. Tahminim SQL Enjeksiyon veya Performans hakkında. Başka herhangi bir şey?
Yanıtlar:
Gerekirse dinamik SQL kullanımıyla ilgili yanlış bir şey yoktur. Aslında bazı durumlarda sahip olduğunuz tek seçenek budur. Evet, girişiniz sterilize edilmezse bir SQL enjeksiyonuna yol açabileceği için kullanılmaması tavsiye edilir ve evet genellikle çağrılan modüllerde dinamik SQL kullanmak performansına zarar verebilir.
Ben kendi başına somut bir örnek olduğunu sanmıyorum ama şunu söyleyebilirim: Önce düzenli sorguları ve ifadeleri kullandıktan sonra ne elde etmeye çalışın - ancak o zaman tüm diğer yolları tükettikten sonra dinamik olarak yapın. Dinamik bir SQL dizesinin yürütülmesinin, onu çağıran modüle ayrı bir kullanıcı oturumunda yapıldığını unutmayın; böylece, beklemediğiniz yerlerde izin sorunlarıyla karşılaşabilirsiniz.
Performans konusunda endişeleriniz varsa; Dene. Güvenlik konusunda endişeleriniz varsa; girişinizi doğrulayın. Doğru ya da yanlış yoktur - yalnızca o sırada kullanabileceğiniz bilgi ve araçlara dayanarak en iyi muhakemenizi kullanırsınız.
Dinamik SQL bir araçtır. Ve bir araç olarak, bazı uygulamaları vardır - örneğin idari işler için bir nimettir.
Özellikle oluşturulan kodun parametrelendirilmesini yönetmediyseniz, uygulamalar tarafından kullanılan SP'de çok iyi değil (SQL Server'ın en son sürümleri sorunları azalttı, ancak yine de geçerli).
Buraya ayrıntılı olarak girmeyeceğim, bu yüzden Dinamik SQL sorunları hakkında mükemmel bir makale önereceğim: MVP Erland Sommarskog'un Curse and Dynamic SQL Blessings .
Çoğu dbms özelliği gibi, eğer doğru durumda kullanırsanız iyi iş yapar, yanlış durumda kötü yapar.
Artıları: Bazı şeyler onsuz yapılamaz. Tipik olarak bu sadece yönetim işi için değil, uygulama kodu için bulduk. Bazı sistem komutları, parametrelerin giriş olarak kullanılmasına izin vermez. Örneğin, her veritabanına karşı bir sproc aracılığıyla, bilinmeyen veritabanları olan birçok durumda bir şey çalıştırmam gerekiyorsa ve komut parametreleri kabul etmiyorsa, bunu genellikle dinamik SQL ile çözerim. Ancak bu Sybase ASE MSSQL daha bir şeydir.
Eksileri: Ben zaten çoktan gitmeyeceğim, çünkü hepimiz zaten bildiğimizi düşünüyorum, ancak yanlış kullanılırsa SQL enjeksiyonu için bazı riskler olabilir. Bana göre daha büyük olanı, sorgunun derlenmiş sorgu planının bir parçası değil, benzersiz bir geçici sorgu gibi davranılmasıdır. Zaman zaman çalışan bir şey için, önemli değil. Dakikada yüzlerce kez yürütülen ve çok sayıda benzersiz sql olacak bir şey için, döngüleri tüketen ve plan önbelleğinin geçerli süresini kısaltan çok sayıda yeni, potansiyel olarak gereksiz sorgu planı oluşturur.
Dinamik SQL kullanmayın.
Zamanın% 99'u Saklı yordamlarda isteğe bağlı parametrelerin nasıl kullanılacağı konusunda bilgi eksikliği nedeniyle Dinamik SQL kullanılır , kalan% 1'i ise müşterinin anlamadığı bir rapor için oldukça karmaşık bir sorgu oluşturmak için kullanılır hatta. Dinamik SQL'in Laneti ve Bereketleri, onu kullanmanın neden iyi bir fikir olabileceğine dair bir örnek göstermez, bunun yerine sadece sorunlu olduğunu gösterir, çünkü SQL'in güvenlik risklerinden bahsetmemek için hata ayıklama, sürdürme karmaşıklığını artırır. Enjeksiyon, zayıf performans önbellek değil, elbette tembel ve naif geçici tablolar ve imleçler kullanmak gibi beraberinde gelen kötü uygulamalar nedeniyleprogramcı kötüye kullanır. Sorguları bu şekilde yazma esnekliği diye bir şey yoktur, SQL bildirimsel bir dildir ve bu şekilde ele alınmalıdır.
Tembellik tüm kötülüklerin köküdür.
Paradoksal olarak, bu cevap en aşağıya düşmüş olanlarda yer alacaktır .