Dünyanın en iyi 3 bilişim danışmanlık firmasından birindeki bir projede çalışıyorum ve bir DBA tarafından şirketin en iyi uygulamasının devlet saklı prosedürlerinin "en iyi uygulama" olmadığı söylendi. Bu öğrendiğim her şeye aykırı.

Saklı yordamlar size kodun yeniden kullanılmasını ve kapsülleme (yazılım geliştirmenin iki sütunu), güvenlik (bir saklı proc üzerindeki izinleri verebilir / iptal edebilirsiniz), sizi SQL enjeksiyon saldırılarından korur ve ayrıca hız konusunda yardımcı olur (DBA’nın SQL Server 2008'den başlayarak, düzenli SQL sorguları bile yeterince çalıştırılırsa derlenir).

Agile yazılım geliştirme metodolojisini kullanarak karmaşık bir uygulama geliştiriyoruz. Saklı procs kullanmak istememelerinin nedenlerini düşünen var mı? Tahminime göre, DBA'lar bu depolanan süreçleri sürdürmek istemedi, ancak böyle bir tasarım kararını haklı çıkarmak için çok fazla olumsuzluk var gibi görünüyor.

Çok büyük projeler üzerinde çalışan tecrübelerime göre, iş mantığının nerede yaşadığı konusunda çok net olmalısınız. Bireysel geliştiricilerin, iş mantığını iş nesnesi katmanına veya uygun gördükleri bir saklı yordam içine koyabileceği bir ortama izin verirseniz, büyük bir uygulamanın anlaşılması ve bakımı ÇOK zor olur.

Saklı yordamlar, belirli DB işlemlerini hızlandırmak için mükemmeldir. Mimari kararım, uygulamanın iş katmanında tüm mantığı bırakmak ve kıyaslamanın garanti edildiğini gösterdiği durumlarda performansı iyileştirmek için saklı yordamları hedeflenen şekilde kullanmaktır.

Bazı Gözlemler

Saklı yordamlar size kodun yeniden kullanılmasını ve kapsüllemeyi (yazılım geliştirmenin iki sütunu) verir,

Bunları yalnızca, kullanılması gereken bağlamda doğru kullanırsanız. Aynı iddia, işlevler (yapısal programlamada) veya yöntemler (nesne yönelimli programlamada) hakkında da söylenebilir ve yine de, 1K işlevlerini ve mega-ass nesnelerini görüyoruz.

Eserler size bu faydaları vermez. Bu eserlerin doğru kullanımı, bu faydaları sağlayan şeydir.

güvenlik (saklanan bireysel işlemlere izin verebilirsiniz / iptal edebilirsiniz),

Evet. Bu iyi bir nokta ve saklı yordamları sevmemdeki temel nedenlerden biri. Genelde sadece görünümler ve kullanıcı hesapları ile elde edilebileceklerden daha hassas bir erişim kontrolü sağlarlar.

sizi SQL enjeksiyon saldırılarından korumak,

Bu, SP'lere özgü değildir, çünkü parametrelenmiş SQL ifadeleri ve giriş fırçalama ile aynı koruma seviyesini sağlayabilirsiniz. Bununla birlikte, SP'leri "derinlemesine güvenlik" olarak da kullanırdım .

ve ayrıca hız konusunda yardımcı olur (DBA, SQL Server 2008'den başlayarak, düzenli SQL sorgularının bile yeterince çalıştırılırsa derlendiğini söylese de).

Bu oldukça veritabanı satıcısına özgüdür, ancak genel olarak DBA'nız doğrudur. SQL ifadeleri (statik veya parametrized) derlenir. SP'ler, basit SQL ifadeleriyle yapamayacağınız verileri toplamanız ve hesaplamanız gerektiğinde / hesapladığınızda, ancak SQL ile sıkı bir şekilde tümleştirildiyse ve uygulama sunucusuna gidiş gelişini garanti etmiyorsa yardımcı olur.

Bunun iyi bir örneği, verileri başka bir SQL'in çalıştırılacağı geçici bir imleç (veya imleçler) içine sorgulamaktır. Uygulama sunucusunda programlı olarak yapabilirsiniz veya db de yaparak çoklu gidiş gelişleri kaydedebilirsiniz.

Ancak bu norm olmamalıdır. Bu vakaların çoğuna sahipseniz, bu kötü veritabanı tasarımının bir işaretidir (ya da departmanlar arasında bu kadar uyumlu olmayan veritabanı şemalarından veri alıyorsunuz).

Agile yazılım geliştirme metodolojisini kullanarak karmaşık bir uygulama geliştiriyoruz.

Çeviklik, teknolojilerle değil, yazılım mühendisliği süreçleri ve ihtiyaç yönetimi ile ilgilidir.

Saklı procs kullanmak istememelerinin nedenlerini düşünen var mı?

Yanlış soru

Soru yanlıştır ve "GOTO'yu kullanmamak için iyi bir sebep var mı?" Niklaus Wirth ile Dijkstra'ya bu konuda daha fazla katılıyorum. Dijkstra'nın hissiyatının nereden geldiğini anlayabiliyorum, ancak her durumda% 100 uygulanabilir olduğuna inanmıyorum. Mağaza procs ve herhangi bir teknoloji ile aynı.

Bir araç, amaçlanan amacı için iyi kullanıldığında ve belirli bir görev için en iyi araç olduğunda iyidir. Aksi halde kullanılması, aletin yanlış olduğunu, ancak avcının ne yaptığını bilmediğini gösterir.

Doğru soru, "ne tür saklı yordam kullanım şekillerinden kaçınılması gerektiği" dir. Veya, "hangi koşullar altında saklı yordamları kullanmalıyım (veya kullanmamalıyım)" . Nedenlerle Looking değil mühendisi içinde - onu ait kare mühendislik sorumluluğu yerleştirmek aksine bir teknoloji basitçe aracı suçu koyuyor kullanmak.

Başka bir deyişle, bu bir kopuş veya cehalet ifadesidir.

Tahminime göre, DBA'lar bu depolanan süreçleri sürdürmek istemedi, ancak böyle bir tasarım kararını haklı çıkarmak için çok fazla olumsuzluk var gibi görünüyor.

O zaman yaptıkları şey kötü mühendislik kararlarının sonuçlarını zayıf kullandıkları araçlara yansıtmak.

Senin durumunda ne yapmalı?

Benim deneyimim, Roma’da Romalılar gibi yapmak .

Onunla savaşma. Şirketinizdeki insanlar mağaza procs'larını kötü bir uygulama olarak etiketlemek istiyorsa, izin verin. Bununla birlikte, mühendislik uygulamalarında bunun bir kırmızı bayrak olabileceğine dikkat edin.

Şeylerin kötü uygulama olarak tipik olarak etiketlenmesi, genellikle tonlarca beceriksiz programcının bulunduğu kuruluşlarda yapılır. Kuruluş, bazı şeyleri kara listeye alarak, içsel olarak verdiği hasarı kendi yetersizliği nedeniyle sınırlamaya çalışır. Ben seni umursamıyorum

Genellemeler, bütün sıkıntıların anasıdır. Depolanan işlemlerin (veya herhangi bir tür teknolojinin) kötü bir uygulama olduğunu söylemek, bu bir genellemedir. Genellemeler yetersiz olanların kopyalarıdır. Mühendisler açık genellemelerle çalışmazlar. Durum bazında analiz yaparlar, analizleri yaparlar ve bir problemi çözmeleri gereken bağlamda eldeki gerçeklere göre mühendislik kararları ve çözümleri uygularlar.

İyi mühendisler, işleri kötü uygulama olarak etiketlememektedir. Probleme bakarlar, uygun olan aracı seçerler, takas yaparlar. Başka bir deyişle, mühendislik yapıyorlar.

Onları nasıl kullanmayacağına dair fikrim

• Onlarda veri toplamanın (ve belki de bazı dönüşümlerin) ötesine karmaşık bir mantık koymayın. Bazı veri masaj mantığını bunlara eklemek veya onlarla yapılan birden çok sorgunun sonucunu toplamak mümkündür. Ama bu konuda. Bunun ötesinde bir şey, başka bir yerde bulunması gereken iş mantığı olarak nitelendirilebilir.

• Bunları SQL enjeksiyonuna karşı tek savunma mekanizması olarak kullanmayın. Onlara kötü bir şeyler yapması durumunda onları orada bırakırsınız , ancak önlerinde bir miktar savunma mantığı olmalı - müşteri tarafında doğrulama / ovma, sunucu tarafında doğrulama / ovma, muhtemelen sizin türünüze anlam veren türlere dönüştürme etki alanı modeli ve nihayet parametreleştirilmiş ifadelere geçilmesi (bu, SQL ifadeleri parametreli hale getirilmiş veya depolanmış işlemlerin parametreleştirilmesi olabilir).

• Veritabanlarını mağaza işlemlerinizi içeren tek yer yapmayın. Mağaza işlemleriniz, C # veya Java kaynak kodunuzu değerlendirdiğiniz gibi işlenmelidir. Yani kaynak, mağaza işleminizin metinsel tanımını kontrol eder. İnsanlar, mağaza işlemlerinin kaynak kontrollü olamayacağını söylüyorlar - saçmalık, ne hakkında konuştuklarını bilmiyorlar.

Bunları nasıl / nerede kullanacakları konusundaki fikrim

• Uygulamanız, birden çok sorgu veya görünümden aktarılması veya toplanması gereken verileri gerektiriyor. Bunu uygulamadan db'ye boşaltabilirsiniz. Burada bir performans analizi yapmanız gerekir, çünkü a) veritabanı motorları bu gibi şeyleri yaparken uygulama sunucularının daha verimli olmasına rağmen, b) uygulama sunucularının (bazen) yatay olarak ölçeklendirilmeleri daha kolaydır.

• İnce taneli erişim kontrolü. Bazı gerizekalı çalışan kartezyen ortaklarının db'nizde yer almasını istemiyorsunuz, ancak insanların böyle bir SQL deyimini de aynı şekilde çalıştırmalarını yasaklayamıyorsunuz. Tipik bir çözüm, geliştirme ve UAT ortamlarında rasgele SQL ifadelerine izin verirken, en sist ve üretim ortamlarında bunları yasaklamaktır. Bunu gizlice veya prodüksiyona sokması gereken her türlü ifade, hem geliştiriciler hem de dbas tarafından kod incelemesi yapılan bir mağaza prosedürüne girer.

Bir mağaza işleminde olmayan bir SQL ifadesini çalıştırmanın herhangi bir geçerli gereksinimi, farklı bir kullanıcı adı / hesap ve bağlantı havuzundan geçer (kullanımı oldukça izlenir ve önerilmez).

• Oracle gibi sistemlerde, sen LDAP erişim elde edebilir veya harici veritabanlarına sembolik oluşturmak (vpn üzerinden bir iş ortağının db üzerinde bir mağaza proc çağırarak söylüyorlar.) Spagetti kod yapmak kolay yolu, ama hepsi programlama paradigmaları için doğru ve bazen Bunun için tek çözüm olan belirli iş / çevre gereksinimleriniz var. Mağaza işlemleri, bu boşluğu tek bir yerde, verilere yakın ve uygulama sunucusuna geçmek zorunda kalmadan kapsüllemeye yardımcı olur.

Bunu db'de mağaza protası olarak mı yoksa uygulama sunucunuzda mı çalıştırdığınız, mühendis olarak yapmanız gereken takas analizine bağlıdır. Her iki seçenek de analiz edilmeli ve bir çeşit analizle gerekçelendirilmelidir. Diğer alternatifi "kötü uygulama" olarak suçlayarak bir yoldan diğerine gitmek, bu sadece bir topal mühendisliği kopyasıdır.

• Uygulama sunucunuzu kolayca ölçekleyemediğiniz durumlarda (.ie. Yeni donanım veya bulut örnekleri için bütçe yoktur), ancak db arka ucunda çok fazla kapasite varsa (bu, birçok kişinin kabul etmek istediği daha tipik) iş mantığını procs depolamak için hareket ettirmek. Güzel değil ve anemik etki alanı modellerine yol açabilir ... ama sonra tekrar ... takas analizi, çoğu yazılımın emdiği şey.

Bunun kalıcı bir çözüm haline gelip gelmediği, o anda gözlenen kısıtlamalara özgüdür.

Umarım yardımcı olur.

Bunun nedeni, saklı bir prosedür katmanına dayanmanın taşınabilirliği sınırlandırması ve sizi belirli bir DB'ye bağlamasıdır. Ek bakım maliyetleri de bir sebep olarak gösterilmektedir. Ayrıca yaptığınız bu noktaya da yorum yapmak istedim:

(saklı yordamlar) sizi SQL enjeksiyon saldırılarından korur

Aslında, sizi düz metin sql sorgulamasında kolayca yapabileceğiniz, sizi koruyan parametreleştirilmiş sorgulamadır.

Saklı procs'ları kabul ettiğim sebeplerden bazıları en iyi uygulama değil.

• İş ve uygulama mantığı, veritabanında olmayan kodda olmalıdır. DB'ye mantık koymak endişeleri karıştırıyor.
• Saklanan procs'ları, konvansiyonel ünite test projelerindeki kod kadar sorunsuz bir şekilde uygulama mantığının kalanıyla test edemezsiniz.
• Saklanan işlemleri kod yazarken ilk programlamayı test etmek için elverişli bulmuyorum.
• Sakladığınız işlemler, IDE'nizde programınızı ayıkladığınızda uygulama kodu gibi hata ayıklamak kadar kolay değildir.
• Versiyon kontrolü / SP'nin normal koduna göre kontrolü

Saklı yordamlar size kodun yeniden kullanılmasını ve kapsüllemeyi (yazılım geliştirmenin iki sütunu) verir,

Evet, ancak diğer çevik tasarım hedeflerini gerçekleştirme pahasına. Bir şey için bakımı daha zor. Bulunduğum projenin herhangi bir göstergesi varsa, büyük olasılıkla aynı işi yapan, hiçbir faydası olmayan birden fazla, uyumlu olmayan SP ile sonuçlanacaksınız.

sizi SQL enjeksiyon saldırılarından korumak,

Hayır. Yapmazlar. Sık sık söylediğini duyduğum gibi, bu fikrin nereden geldiğini tahmin etmeye bile başlayamıyorum ve bu doğru değil. Bazı SQL enjeksiyon saldırı türlerini hafifletebilir, ancak parametreli sorguları ilk etapta kullanmıyorsanız, bunun önemi yoktur. Hala yapabilirim '; DROP TABLE Hesapları; -

ve ayrıca hız konusunda yardımcı olur (DBA, SQL Server 2008'den başlayarak, düzenli SQL sorgularının bile yeterince çalıştırılırsa derlendiğini söylese de).

Ayrıca, hazır, parametreleştirilmiş ifadeler kullandığınızda da (en azından kullandığım DB'lerin çoğuyla) derlenirler. Uygulamanız sorguyu çalıştırmaya başladığında (veya özellikle aynı sorguyu birden çok kez çalıştırdığınızda), SP'nizin sahip olduğunu düşündüğünüz herhangi bir performans avantajı tamamen karışmaz.

Sadece bir saklı yordam, IMHO, kullanımı nedeni birden fazla harmanlanmış kaynaklardan çeker karmaşık, çok aşamalı sorgu yapmak gerekir ne zaman olacağı. SP'ler düşük seviye karar mantığı içermemeli ve hiçbir zaman basit bir sorguyu basitçe içermemelidir . Avantaj yok ve sadece birçok sakınca var.

DBA'nızı dinleyin. Neyin olduğunu biliyor.

Birkaç yıl önce Büyük Beşlerden biri için çalıştığımda bu resmi çizgi oldu. Bunun nedeni, SP'lerin belirli uygulamalara bağlı olmasından (PL / SQL - T / SQL vs ...), gereksiz yere teknoloji seçimlerini sınırlamalarıydı.

Büyük bir sistemin T / SQL'den PL / SQL'e geçişi ile yaşamış, argümanı anlayabiliyorum. Bence bir canar biraz - Ben bir kapris üzerinde bir kaprisin içinde gerçekten kaç yer gerçekten taşınır?

Çalıştığım firmaların üçü de kendi uygulama mantıkları için SQL Server ile kullanılan saklı yordamları kullandı. Olayları başka şekilde görmedim. Ama bana göre onlar büyük bir karmaşa. Genellikle çok iyi hata işleme tesisleri yoktur veya saklı yordamlarla yeniden kullanım olanakları yoktur.

Diyelim ki kullanmak istediğiniz veri kümesini döndüren saklı bir yordamınız var, gelecekteki saklı yordamlarda nasıl kullanabilirsiniz? Bunun için SQL Server'daki mekanizmalar çok iyi değil. EXEC INTO ... sadece bir veya iki seviyeye kadar yuva yapar (şimdi unutuyorum). Veya bir çalışma masasını önceden tanımlamanız ve işlemi kilitlemeniz gerekir. Veya geçici bir tablo hazırlamanız ve yordamın doldurmasını istemeniz gerekir. Ancak, iki kişi aynı anda hiç kullanmayı planlamadıkları iki farklı prosedürde aynı şeyi geçici tablo olarak adlandırırsa ne olur? Herhangi bir normal programlama dilinde, bir diziyi bir işlevden veya noktadan aralarında paylaşılan bir nesneye / küresel yapıya döndürebilirsiniz (yalnızca küresel yapıyı değiştirmek yerine veri yapısını döndüreceğiniz işlevsel diller hariç) ... )

Yeniden kod kullanımı nasıl olur? Ortak ifadeleri UDF'lere (veya daha da kötüsü alt sorgular) eklemeye başlarsanız, kodu durduracaksınız. Bir sütun için hesaplama yapmak için saklı bir prosedürü çağıramazsınız (imleç kullanmıyorsanız, sütun değerlerini birer birer geçirin ve ardından tablonuzu / veri kümenizi bir şekilde güncelleyin). Temel olarak, en iyi performansı elde etmek için, bakım kabusu olan her yerdeki ortak ifadeleri kesmeniz / yapıştırmanız gerekir ... Bir programlama diliyle, ortak SQL oluşturmak için bir işlev oluşturabilir ve daha sonra bunu oluştururken her yerden çağırabilirsiniz. SQL dizesi. O zaman formülü ayarlamanız gerekiyorsa, değişikliği tek bir yerde yapabilirsiniz ...

Hata işlemeye ne dersiniz? SQL Server, saklı yordamın çalışmasını derhal durduran ve bazılarının bağlantı kesilmesine zorlayan birçok hata vardır. 2005'ten beri deneme / yakalama var ama hala yakalanamayan çok sayıda hata var. Ayrıca aynı şey, hata işleme kodunda kod çoğaltmasıyla da olur ve istisnaları gerçekten kolay bir şekilde iletemez veya çoğu programlama dilinden daha yüksek seviyelere çıkaramazsınız.

Ayrıca sadece hız. Veri kümeleri üzerindeki birçok işlem SET odaklı değildir. Satır yönelimli şeyler yapmaya çalışırsanız, bir imleç kullanacaksınız veya bir imleç kullanacaksınız (geliştiriciler her satırı birer birer birer birer sorguladığında ve içeriği bir imleç gibi @ değişkenlerinde sakladığınızda). ..Bu çoğu zaman bir FORWARD_ONLY imlecinden daha yavaş olsa da). SQL Server 2000 ile öldürmeden önce 1 saat boyunca çalışan bir şey vardı. Bu kodu Perl'de yeniden yazdım ve 20 dakika içinde bitmişti. C'den 20-80x daha yavaş bir komut dosyası dili performansta SQL'i içtiğinde, kesinlikle SQL'de satır yazma işlemleri yapmanıza gerek kalmaz.

Şimdi SQL Server CLR entegrasyonuna sahip ve bir CLR saklı yordam kullanıyorsanız bu sorunların çoğu ortadan kalkar. Ancak birçok DBA, .NET programları yazmayı veya güvenlik endişeleri nedeniyle CLR'yi kapatmayı ve Transact SQL'e sadık kalmayı bilmemektedir. .

Ayrıca genel olarak ölçeklendirilmesi en zor olan şey veritabanıdır. Tüm iş mantığınız veritabanındaysa, veritabanı çok yavaşladığında sorunlarınız olacaktır. Bir işletme katmanınız varsa, performansı artırmak için daha fazla önbellek ve daha fazla iş sunucusu ekleyebilirsiniz. Geleneksel olarak windows / linux yüklemek ve .NET / Java çalıştırmak için başka bir sunucu, başka bir veritabanı sunucusu satın almak ve daha fazla SQL Server lisanslamaktan çok daha ucuzdur. SQL Server şu anda daha fazla kümelenme desteğine sahip olsa da, aslında herhangi bir özelliği yoktu. Bu nedenle, çok paranız varsa, birden fazla salt okunur kopya elde etmek için kümeleme ekleyebilir veya hatta bazı günlük nakliyeleri yapabilirsiniz. Ancak genel olarak bu, önbellek veya benzeri bir şeyin arkasına yazı yazmaktan çok daha pahalıya mal olacak.

Ayrıca Transact-SQL tesislerine bakın. Dize Manipülasyonu? Java String Class / Tokenizer / Scanner / Regex derslerini her gün alacağım. Karma Tablolar / Bağlantılı Listeler / Etc Java Koleksiyonu çerçevelerini vs. alacağım. Ve aynı şey .NET için de geçerli ... Hem C # hem de Java, Transact SQL'den çok daha gelişmiş dillerdir. .

Ayrıca, depolanan prosedürler, büyük bir veri kümesiyle çalışmak ve bunları iş katmanına döndürmeden önce küçültmek için birden çok sorgu / ölçüt uygulamak için daha etkilidir. İstemci uygulamasına bir sürü büyük veri kümesi göndermek ve istemcideki verileri parçalamak zorunda kalırsanız, sunucudaki tüm işleri yapmaktan çok daha fazla verimsiz olacaktır.

Ayrıca saklı prosedürler güvenlik için iyidir. Tüm temel tablolara erişimi kesebilir ve yalnızca saklı yordamlar aracılığıyla erişime izin verebilirsiniz. XML gibi bazı modern tekniklerle toplu güncellemeler yapan saklı yordamlara sahip olabilirsiniz. Daha sonra, tüm girişler güvenli / doğru olduğu sürece verilerin daha fazla bütünlüğe sahip olması için saklı prosedürlerle kontrol edilir.

Programlama dilindeki sorguları parametreleştirdiğimiz için SQL enjeksiyon argümanı artık pek geçerli değil. Ayrıca gerçekten parametreli hale getirilmiş sorgulardan önce bile bir miktar değiştirme ("'", "' '") çoğu zaman çalıştı (yine de ne istediğinizi elde etmek için ipin sonundan geçmek için kullanılabilecek püf noktaları olsa da).

Genel olarak SQL ve Transact SQL'in veri sorgulama / güncelleme için harika diller olduğunu düşünüyorum. Ancak herhangi bir mantık türünü kodlamak için, dize manipülasyonu (veya heck dosya manipülasyonu… xp_cmdshell .... ile neler yapabileceğinizi görünce şaşıracaksınız). Çoğunlukla saklı yordamları kullanmayan gelecekteki bir yer bulmayı umuyorum. Kodların bakımları açısından bakıldığında kabuslar. Ayrıca platformları değiştirmek istiyorsanız ne olur (gerçekte Oracle / DB2 / Sybase / Sql Server / vb. İçin ödeme yapmış olsanız bile), size yardımcı olabilecek her bir uzantıyı kullanarak onlardan alabileceğiniz her şeyi alabilirsiniz. ..).

Ayrıca şaşırtıcı bir şekilde çoğu zaman iş mantığı aynı değildir. İdeal dünyada tüm mantığı saklı yordamlara dahil eder ve bunu uygulamalar arasında paylaşırsınız. Ancak, çoğu zaman mantık uygulamalara ve farklı prosedürlere dayanarak farklılık gösterir ve insanların değişmekten korktukları ve tüm etkilerini anlamadıkları aşırı karmaşık monolitler haline gelir. Oysa iyi bir nesne yönelimli dili ile, her uygulamanın kendi ihtiyaçlarına göre geçersiz kılabileceği bazı standart arayüz / kancalara sahip bir veri erişim katmanını kodlayabilirsiniz.

Sunucudaki saklı yordamları nasıl sürümlendiriyorsunuz?

Saklı yordamları sunucuya sürüm denetiminden yeniden uygularsanız, saklanan yürütme planını temizlersiniz.

Saklı yordamlar doğrudan sunucuda değiştirilebilir olmamalıdır, aksi halde şu anda gerçekten neyin çalıştığını nasıl biliyorsunuz? Olmazlarsa, dağıtım aracının saklı yordamları veritabanına yazma erişimine ihtiyacı vardır. Her yapıda konuşlandırmanız gerekecek (yürütme planının farklı olması gerekebilir)

Saklı yordamlar taşınabilir olmasa da, genel olarak SQL de yoktur (şimdiye dek kehanet tarihi işlenmesi - uggghhh).

Bu nedenle, taşınabilirlik istiyorsanız, bir iç veri erişim API'si oluşturun. Buna benzer işlev çağrıları çağırabilir ve dahili olarak parametreli sorgularla istediğiniz dilde inşa edebilirsiniz ve sürüm kontrollü olabilir.

Bu öğrendiğim her şeye aykırı.

Daha fazla dışarı çıkman gerekebilir. [sırıtış] Cidden, depolanan süreçler en az 10 yıldır düşüş gösteriyor. N-katmanlı, istemci-sunucu değiştirildiğinden beri. Düşüş sadece Java, C #, Python vb. OO dillerinin benimsenmesiyle hızlandı.

Saklanan süreçlerin hala savunucularının ve savunucularının olmadığı söylenemez - ama bu uzun zamandır devam eden bir tartışma ve tartışma. Yeni değil ve muhtemelen bir süredir devam edecek; IMO, depolanan procsların rakiplerini açıkça kazanıyor.

Saklı yordamlar size kodun yeniden kullanılmasını ve kapsüllemeyi (yazılım geliştirmenin iki sütunu) verir.

Çok doğru. Ancak, terbiyeli bir mimariye sahip OO katmanı da öyle.

güvenlik (saklanan bireysel işlemlerde izinleri verebilir / iptal edebilirsiniz)

Bunu yapabilseniz de, ciddi kısıtlamalar nedeniyle çok az kişi bunu yapabilir. DB seviyesindeki güvenlik, içeriğe duyarlı kararlar verecek kadar ayrıntılı değildir. Performans ve yönetim ek yükü nedeniyle, kullanıcı başına bağlantıların olması da olağandışıdır - bu nedenle uygulama kodunuzda hala bir düzeyde yetkilendirme yapmanız gerekir. Rol tabanlı girişleri kullanabilirsiniz, ancak bunları yeni roller için oluşturmanız, hangi rolde çalıştığınızı sürdürmeniz, "sistem düzeyinde" işleri günlüğe kaydetme gibi çalışması için değiştirmeniz gerekir. Ve sonuçta uygulamanız varsa aittir - DB ile bağlantınız.

seni SQL enjeksiyon saldırılarından koru

Parametreli sorgu yapmaktan başka bir şey yok. Yine de yapman gereken şey.

ve ayrıca hız konusunda yardımcı olur (DBA, SQL Server 2008'den başlayarak, düzenli SQL sorgularının bile yeterince çalıştırılırsa derlendiğini söylese de).

Bunun MSSQL 7 veya 2000'de başladığını düşünüyorum. Satır içi SQL performansında depolanan proc ile ilgili birçok tartışma, ölçüm ve yanlış bilgi var - hepsini YAGNI altında topluyorum. Ve ihtiyacın olursa test et.

Agile yazılım geliştirme metodolojisini kullanarak karmaşık bir uygulama geliştiriyoruz. Saklı procs kullanmak istememelerinin nedenlerini düşünen var mı?

Sana ediyorum birçok nedenden düşünemiyorum istemek için. Java / C # / herhangi bir 3. GL dili, kapsülleme, yeniden kullanım ve kolaylık gibi konularda T-SQL'den çok daha yeteneklidir.

Ayrıca, "gerektiği gibi dağıtılması, ancak daha fazlası değil" tavsiyesi verildi - bugünlerde ispat külfetinin SP savunucuları üzerinde olduğunu düşünüyorum. Proc ağır depolanmasının yaygın bir nedeni, T-SQL'in OO'dan daha kolay olması ve mağazanın OO'dan daha iyi T-SQL dev'lerine sahip olmasıdır. Veya, DBA'nın veritabanı katmanında durduğunu ve kaydedilen işlemlerin dev ve DBA arasındaki arayüz olduğunu gösterir. Veya yarı özel bir ürün gönderiyorsunuz ve depolanan işlemler kullanıcı tarafından özelleştirilebilir. Bunun gibi bazı düşünceler olmasaydı, bugünlerde herhangi bir Çevik SW projesi için varsayılanın ORM olacağını düşünüyorum.

Yukarıdaki tüm durumları göz önüne alarak bir tane daha eklemek istiyorum. SP'nin seçimi insanların seçimine de bağlı olabilir.

İnsanlar SP'ye çok karmaşık bir mantık koyduğunda kendimi hayal kırıklığına uğrattığımı ve böyle bir SP'nin sürdürmek ve hata ayıklamak için çok karmaşık olduğuna inanıyorum. Pek çok durumda bile, geliştiricinin kendisi kodda hata ayıklama yaparken sorunla karşılaşıyor (diyelim ki) SP'den çok daha kolay.

SP sadece basit işlemler için kullanılmalıdır. Benim seçimim bu.

Saklı işlemlerle ilgili bazı sorunları ve sorunları ele almak istiyorum. Onları yoğun bir şekilde LedgerSMB ile kullanıyoruz ve kuralımız, çok özel bir uzantısı olan "bir sorgu ise, saklı bir işlem yapması".

Bunu yapmamızın nedeni, diller arası sorgunun yeniden kullanılmasını kolaylaştırmaktı. Bunu dürüstçe yapmanın daha iyi bir yolu yok.

Sonunda soru her zaman ayrıntıda açık. İyi kullanılmış, saklı yordamlar işleri çok kolaylaştırır ve kötü kullanıldığında işleri daha da zorlaştırır.

Yani con tarafına.

1. Geleneksel olarak kullanıldığı gibi, saklı prosedürler kırılgandır. Yalnızca kullanıldıklarında, arama sözdiziminin değişmesinden başka bir sebep olmadan beklemediğiniz yerlerde kodunuza hata ekleme imkanı yaratırlar. Yalnız kullanıldığında bu biraz problemdir. Katmanlar arasında çok fazla uyum var ve bu sorunlara neden oluyor.

2. Evet, herhangi bir dinamik sql yapılıyorsa sproc sql enjeksiyonu yapılabilir. Bu alanda aşırı güven duyulması kötü bir şeydir ve sonuç olarak bu alanda güvenlik konusunda önemli deneyime sahip olmak gerekir.

3. Arabirimlerdeki değişiklikler yukarıda belirtilen 1. nedenden dolayı saklı yordamlarda biraz sorunludur, ancak çok sayıda istemci uygulaması söz konusu olduğunda bu çok büyük bir kabus olabilir.

Yukarıdakileri inkar etmek oldukça zor. Onlar olur. SP yanlısı ve SP karşıtı olan herkesin bunlarla ilgili korku hikayeleri vardır. Sorunlar çözülemez değildir, ancak bunlara dikkat etmezseniz, onları çözemezsiniz (LedgerSMB’de, çalışma zamanında dinamik olarak SP çağrıları oluşturmak, yukarıdaki sorunlardan kaçınmak için bir servis bulucu kullanıyoruz. sadece benzer bir şey diğer db'ler için yapılabilir).

Pozitiflere. Yukarıdaki problemleri çözebileceğinizi varsayarsak, şunları elde edersiniz:

1. Set işlemlerinde gelişmiş netlik imkanı. Sorgunuz çok büyükse veya çok esnekse, bu özellikle doğrudur. Bu aynı zamanda gelişmiş test edilebilirliğe yol açar.

2. Zaten bu alanda çalışan bir servis bulucum varsa, saklı prosedürlerin geliştirme hızını hızlandırdığını, çünkü uygulama geliştiricisini db endişelerinden kurtarıyorlar; Bunun doğru yapmada bazı zorlukları var ama bunu yapmak zor değil.

3. Sorgu yeniden kullanın.

Oh ve bir SP'de neredeyse hiç yapmamanız gereken bazı şeyler:

1. işlemsel olmayan mantık. Siparişin gönderildiği e-postayı gönderdiniz ancak işlem geri alındı ​​... ya da şimdi e-posta sunucusunun çevrimiçi olması için devam etmeyi bekliyorsunuz .... ya da daha kötüsü, ulaşamadığınız için işleminizi geri aldınız e-posta sunucusu ....

2. gevşek bir sürü küçük sorgu bir araya sokuldu, prosedürel mantıkla serpildi.

Kim için çalışıyorsun?

Cevap, kimler tarafından işe alındığına, danışmanlık firmasına veya şirketin kendisine bağlı olabilir. Bir şirket için en iyisi, bir danışmanlık firması veya başka bir yazılım satıcısı için çoğu zaman en iyisi değildir. Örn: Akıllı bir şirket rakiplerine göre kalıcı bir avantaja sahip olmayı arzu eder. Buna karşılık, bir yazılım satıcısı, belirli bir sektördeki tüm işletmeler için aynı çözümü en düşük maliyetle yakalayabilmek istiyor. Bu konuda başarılı olursa, müşteri için net bir rekabet avantajı olmayacaktır.

Bu özel durumda, başvurular gelir ve gider, ancak çok sık, kurumsal veritabanı sonsuza kadar yaşar. Bir RDBMS'nin yaptığı en önemli şeylerden biri, önemsiz verilerin veritabanına girmesini engellemektir. Bu saklı yordamları içerebilir. Eğer mantık iyi bir mantıksa ve yıldan yıla değişme olasılığı yüksek değilse, veritabanını kullanmak için ne şekilde yazılmış olursa olsun, neden veritabanında olmamalı, dahili olarak tutarlı tutmalı? Yıllar sonra birileri veritabanından sormak istedikleri bir soru olacak ve önemsizlerin DB'ye girmesi engellenmişse cevap verilebilir.

Belki de bunun DBA’nizin bir danışmanlık firması için çalışması gerçeğiyle ilgisi var. Kodlarını ne kadar taşınabilirlerse, istemciden istemciye kodu o kadar çok kullanabilirler. Uygulamasında ne kadar çok mantık kurabilirlerse, şirket satıcıya o kadar fazla bağlanır. Süreçte büyük bir karmaşa bıraktıklarında, temizlemek için para alacaklar ya da karmaşayı bir daha asla görmeyecekler. Her iki durumda da onlar için bir kazanç.

Çitin her iki tarafında (çok) daha fazla tartışma için kodlama korkularındaki tartışmayı okuyun . FWIW SP’leri savunanların tarafına yaslanıyorum.

Veritabanı markalarını değiştirmek ve aynı saklı yordamları kullanmak çok zor.

Takımınızın DBA'sı yok ve hiç kimse sql ile bir şey yapmak istemiyor.

Bu, bir programcı v DBA pissing yarışmasından başka bir şey değil.

IMO buna bağlı. Saklı prosedürlerin kendi yerleri vardır, ancak en iyi uygulama değildirler ve ne pahasına olursa olsun kaçınılması gereken bir şey değildir. Akıllı bir geliştirici verilen bir durumu doğru şekilde değerlendirmeyi ve saklı bir prosedürün cevap olup olmadığını belirlemeyi bilir. Şahsen, belki önceden tanımlanmış raporlar veya benzeri durumlar dışında saklı prosedürlerden ziyade bir tür ORM (ham Linq to Sql gibi basit bir tane bile) kullanma hayranıyım ama yine de durum bazında.

İş mantığını farklı programlama dilleri kullanarak farklı katmanlara ayırmak her zaman bir sorun kaynağıdır. Bir böcek izlemek veya bir değişiklik uygulamak, dünyalar arasında geçiş yapmanız gerektiğinde çok daha zordur.

Bu, tüm iş mantığını veritabanında yaşayan PL / SQL paketlerine yerleştirerek oldukça iyi iş yapan şirketleri biliyorum . Bunlar çok büyük uygulamalar değil, aynı zamanda önemsiz değiller; 20K-100K LOC. (PL / SQL, bu tür bir sistem için T-SQL'den daha uygundur, bu nedenle yalnızca T-SQL'i biliyorsanız, muhtemelen şimdi inkar edin ...

Bu henüz belirtilmeyen başka bir nokta:

Kod oluşturma araçları ve tersine mühendislik araçları, saklı yordamlarla gerçekten iyi baş edemez. Araç genellikle işlemin ne yaptığını söyleyemez. Proc bir sonuç kümesi döndürüyor mu? Birkaç sonuç seti? Sonuç kümelerini birkaç tablodan ve geçici tablolardan alıyor mu? Proc yalnızca kapsüllenmiş bir güncelleme bildirimi midir ve hiçbir şey döndürmez mi? Sonuç kümesi, dönüş değeri ve bazı "konsol çıkışı" döndürüyor mu?

Bu nedenle, otomatik olarak veri aktarım nesnesi DTO ve DAO katmanı oluşturmak için bir araç kullanmak istiyorsanız (örneğin, liferay'ın "servis kurucusu") bunu kolayca yapamazsınız.

Ayrıca, Hazırda Bekletme gibi ORM'ler, veri kaynağı bir SP olduğunda gerçekten düzgün çalışamaz. Veri erişimi en iyi şekilde salt okunurdur.

Yalnız Programlama, ben duramazlar yazı saklı yordamlar.

Öncelikle MySQL kullanıyorum. PostGreSQL gibi daha önce nesne yönelimli veritabanları kullanmadım, ancak MySQL'deki SP'ler ile yapabileceğim şey tablo yapısını biraz soyutlamak. SP en Beni kimin giriş ve çıkışları bu ilkel eylemleri tasarlamak için izin değişmeyecek altındaki veritabanı bile gelmez değiştirin.

Bu yüzden denilen bir prosedür var logIn. Giriş yaptığınızda, her zaman sadece usernameve geçer password. Geri gönderilen sonuç tamsayıdır userId.

Ne zaman logInbir saklı yordam, şimdi ben de ilk oturum ile aynı anda olur Giriş sırasında yapılması gereken ek iş ekleyebilir. Ben saklı yordam gömülü mantığı ile SQL tabloların bir dizi bulmak yazmak daha kolay (çağırmaktan daha FETCH ortamı) -> (sonuç almak) -> (FETCH ortamını çağırmak) serisini mantık sunucusu tarafınızı yazarken yapmanız gerekir.

Ayrıca saklı yordamların sunucuda cpu zamanını kullandığını belirtmek istiyorum. Çok değil, biraz. İş prosedüründe yapılan çalışmaların bazıları uygulamada yapılabilir. Uygulama katmanını ölçeklendirmek veri katmanından daha kolaydır.

Mark'la topluluğun bir süredir saklı yordamlardan gerçekten uzaklaştığını kabul ediyorum. Orijinal posterin neden SP'leri kullanmak isteyebileceğimizi dile getirdiği noktaların birçoğu bir zamanlar geçerliydi, uzun zaman oldu ve bir başka afişin dediği gibi çevre değişti. Mesela, SP'leri 'gün içinde geri' kullanmanın bir argümanını hatırlıyorum, çünkü elde edilen performans kazanımları, yürütme planları 'önceden derlenmiş' iken, kodumuzdaki dinamik SQL her yürütme ile yeniden derlendi. Bu artık büyük veritabanları değiştiği, geliştirdiği, uyarladığı vb. Durumlarda geçerli değildir.

Bu, şu anki projemde SP kullanıyoruz. Bunun nedeni, halen eski uygulamaları destekleyen mevcut bir veritabanının üzerine yeni uygulamalar oluşturmamızdır. Sonuç olarak, eski uygulamaları kapatıncaya kadar şema değişikliklerini yapmak çok zordur. Uygulama için gerekli olan davranış ve kurallara dayanarak yeni uygulamalarımızı tasarlamak ve SP'leri olmasını istediğimiz gibi veri tabanıyla geçici olarak arayüz oluşturmak ve SP'lerin mevcut SQL'e uyum sağlamasına izin vermek için bilinçli bir karar verdik. . Bu, önceki bir posterin görüşüne göre, SP'ler, uygulama kodunda değişiklik yapmak zorunda kalmadan, veritabanı düzeyinde değişiklik yapmayı kolaylaştırır. SP'leri Adaptör modelinin bir uygulaması olarak kullanmak kesinlikle benim için anlamlı (özellikle şu anki projeme göre),

Fwiw, şema güncellendiğinde SP'leri kaldırmak niyetimizdir. Ancak, kurumsal gelişimdeki diğer her şeyde olduğu gibi, bunun gerçekleşip gerçekleşmeyeceğini göreceğiz! [sırıtış]

Saklı yordamları nasıl önereceğime dair kısa bir özet yapmak istedim. Onların kötü bir uygulama olduğunu sanmıyorum ve diğerlerinin de dediği gibi uygun durumlarda kullanılması gerektiğini düşünüyorum.

Farklı uygulamalar için yazma prosedürlerinin işlevsellik açısından kafa karıştırıcı hale gelebileceği ve uygulamanın iş mantığını ayırabileceği ve veritabanının daha düzensiz ve kısıtlayıcı hale gelmesine neden olabilecek sorunları görebiliyorum.

Bu nedenle, veritabanına özgü ilişkisel veri odaklı görevlerde saklı bir prosedür kullanırdım. Başka bir deyişle, herhangi bir uygulamanın verisiyle tutarlı veritabanı işlemleri için kullanılan bir mantık varsa, verileri tutarlı bir şekilde saklamak için saklı bir prosedür kullanılabilir (mantıklı). Bunun iyi örnekleri olduğunu düşünüyorum: tutarlı kayıt, tutarlı bakım, hassas bilgilerle çalışmak, vb.

Diğer görevler, veri tabanının güçlü veri modelini takip eden uygulamanın gereksinimlerine uyacak şekilde veriyi manipüle etmeyi düşünüyorum, sanırım iş mantığını içeren başka bir katmanda saklanmalıdır. Kısacası, tutarlılık için veri tabanına özel veri manipülasyonu, tutarlılığın veri tabanı bütünlüğü şema modelini geçtiği saklı prosedürleri kullanabilir.

Saklı yordamlar "benim için" OLAP "salt okunur" işlemler, nadir kullanım için uygundur.

İş kuralları için OLTP okuma / yazma işlemleri Java uygulama sunucularını tercih ederim. Kodlama kolaylığı ve mümkün olduğunca master db sunucularından cpu ve bellek yükünü hafifletmek için. Bu kurulumda, uygulama sunucularındaki tüm kodların gözden geçirilmesi veya kaydedilmesi zor değildir ve ölçeklenebilir.

Benim için önemli olan iş katmanında hata ayıklamak, saklı yordamları ayıklamaktan daha kolaydır.

İş mantığını gereksiz yere dağıtmanın ve sizi belirli bir veritabanı satıcısına bağlamanın yanı sıra, amaçlanan şey için bir teknoloji kullanmaya da inanıyorum. Bir veritabanı sadece, ilişkisel bir veri deposudur. Veri depolamak için kullanın, başka bir şey yok.

Araçlarınızı akıllıca seçin ve uzun vadede kendinizi incinmiş bir dünyadan kurtarın.