Dünyanın en iyi 3 BT danışmanlık şirketinden birinde bir projede çalışıyorum ve bir DBA tarafından şirketin en iyi uygulamasının devlet tarafından saklanan 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üllenmeyi (yazılım geliştirmenin iki sütunu), güvenlik (tek bir depolanmış proc için izinler verebilir/iptal edebilirsiniz), sizi SQL enjeksiyon saldırılarından koruyabilir ve aynı zamanda hıza yardımcı olabilir (DBA, SQL Server 2008 ile başlayarak, düzenli SQL sorgularının bile yeterli sayıda çalıştırıldıklarında derlendiği).
Agile yazılım geliştirme metodolojisini kullanarak karmaşık bir uygulama geliştiriyoruz. Depolanmış proc'ları kullanmak istememelerinin iyi nedenlerini düşünen var mı? Tahminimce, DBA'lar bu depolanmış procları korumak istemiyordu, 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ışma deneyimime göre, iş mantığının nerede yaşadığına çok açık olmalısınız. Bireysel geliştiricilerin iş mantığını iş nesnesi katmanına veya uygun gördükleri şekilde saklı bir yordama koyabilecekleri bir ortama izin verirseniz, büyük bir uygulamanın anlaşılması ve bakımı ÇOK zorlaşır.
Saklı yordamlar belirli DB işlemlerini hızlandırmak için mükemmeldir. Mimari kararım, tüm mantığı uygulamanın iş katmanında bırakmak ve kıyaslamanın gerekli olduğunu gösterdiği durumlarda performansı artırmak için saklı yordamları hedefli bir şekilde kullanmaktır.
Saklı yordamlar size kodun yeniden kullanılmasını ve kapsüllenmesini sağlar (yazılım geliştirmenin iki sütunu),
Yalnızca bunları, kullanılması gerektiği bağlamda doğru kullanırsanız. Aynı iddia işlevler (yapılandırılmış programlamada) veya yöntemler (nesne yönelimli programlamada) hakkında da söylenebilir, ancak 1K işlevleri ve mega-ass nesneleri görüyoruz.
Eserler size bu faydaları sağlamaz. Bu eserlerin doğru kullanımı, bu faydaları sağlayan şeydir.
güvenlik (tek bir depolanmış proc için izinler verebilir/iptal edebilirsiniz),
Evet. Bu iyi bir nokta ve saklı yordamları sevmemin ana nedenlerinden biri. Yalnızca görünümler ve kullanıcı hesaplarıyla tipik olarak elde edilebileceklerden daha hassas bir erişim denetimi sağlarlar.
sizi SQL enjeksiyon saldırılarına karşı korur,
Parametreli SQL ifadeleri ve giriş fırçalaması ile aynı düzeyde koruma sağlayabildiğiniz için bu SP'lere özgü değildir. SP = Ben bunlara ek olarak kullanmak istiyorum, ancak, "derinlik güvenlik".
ve aynı zamanda hız konusunda da yardımcı oluyor (DBA, SQL Server 2008'den başlayarak, düzenli SQL sorgularının bile yeterli sayıda çalıştırıldıklarında derlendiğini söyledi).
Bu son derece veritabanı satıcısına özeldir, ancak genel olarak DBA'nız doğrudur. SQL deyimleri (statik veya parametreli) derlenir. SP'ler, basit SQL ifadeleriyle yapamayacağınız, ancak SQL ile sıkı bir şekilde entegre olduğunuz ve uygulama sunucusuna gidiş gelişini garanti etmeyen verileri toplamak ve hesaplamak istiyorsanız/gerekiyorsa yardımcı olur.
Buna iyi bir örnek, verileri başka bir SQL'in çalıştırılacağı geçici bir imleç (veya imleçler) şeklinde sorgulamaktır. Uygulama sunucusunda programlı olarak yapabilir veya db'de yaparak birden fazla gidiş dönüş kaydedebilirsiniz.
Ancak bu norm olmamalıdır. Bu durumların çoğuna sahipseniz, bu kötü veritabanı tasarımının bir işaretidir (veya bölümler arasında çok uyumlu olmayan veritabanı şemalarından veri çekiyorsunuzdur.)
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 gereksinim yönetimleriyle ilgilidir.
Depolanmış proc'ları kullanmak istememelerinin iyi nedenlerini düşünen var mı?
Soru yanlış ve "GOTO'yu kullanmamak için iyi nedenler var mı?" Bu konuda Dijkstra'dan daha Niklaus Wirth ile yan yana. Dijkstra'nın duyguları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 kullanmak aletin yanlış olduğunun bir göstergesi değil, wielder'ın ne yaptığını bilmediğidir.
Doğru soru "ne tür saklı yordam kullanım kalıplarından kaçınılması gerektiğidir." Veya, "saklı yordamları hangi koşullarda kullanmam (veya kullanmamam)". Sebepleri aramak değil bir teknoloji kullanmak, sadece mühendislik sorumluluğunu ait olduğu yere - mühendisin içine yerleştirmek yerine suçu aletin üzerine koymaktır.
Başka bir deyişle, bir dışlama veya cehalet ifadesidir.
Tahminimce, DBA'lar bu depolanmış procları korumak istemiyordu, 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ı kötü kullandıkları araçlara yansıtmaktır.
Benim deneyimim, Roma'da Romalılar gibi yapın.
Kavga etme. Şirketinizdeki kişiler mağaza işlemlerini kötü bir uygulama olarak etiketlemek istiyorsa, bırakın. Bununla birlikte, bunun mühendislik uygulamalarında kırmızı bir bayrak olabileceğini unutmayın.
Kötü uygulama olarak şeylerin tipik etiketlenmesi genellikle tonlarca yetersiz programcıya sahip kuruluşlarda yapılır. Kuruluş, belirli şeyleri kara listeye alarak, kendi yetersizlikleri nedeniyle dahili olarak verilen zararı sınırlamaya çalışır. Sana değilim.
Genellemeler, tüm vidaların annesidir. Depolanmış süreçlerin (veya herhangi bir teknoloji türünün) kötü bir uygulama olduğunu söylemek, bu bir genellemedir. Genellemeler, beceriksizlerin dışarı çıkmasıdır. Mühendisler açık genellemelerle çalışmazlar. Durum bazında analiz yaparlar, bir problemi çözmeleri gereken bağlamda eldeki gerçeklere göre mühendislik kararları ve çözümler üretir ve mühendislik kararları ve çözümleri uygularlar.
İyi mühendisler, bu tür genelleme yollarıyla işleri kötü uygulama olarak etiketlemezler. Soruna bakarlar, uygun aracı seçerler, takas yaparlar. Başka bir deyişle, mühendislik yapıyorlar.
İçlerinde veri toplamanın (ve belki de bazı dönüşümlerin) ötesine karmaşık mantık koymayın. Onlara bazı veri masaj mantığı koymak ya da onlarla birden çok sorgu sonucunu toplamakta sorun yoktur. Ama bu kadar. Bunun dışındaki her şey, başka bir yerde bulunması gereken iş mantığı olarak nitelendirilir.
Onları SQL enjeksiyonuna karşı tek savunma mekanizması olarak kullanmayın. Onları orada bırakın kötü bir şey onlara yaparsa, ama bir dönüş olmalı savunma mantığının önü - istemci tarafı doğrulama/ovma, sunucu tarafı doğrulama/ovma, etki alanı modelinizde anlamlı olan türlere dönüşme ve son olarak parametrelenmiş ifadelere (parametrelenmiş SQL deyimleri veya parametrelenmiş olabilir) geçme kayıtlı proks.)
Veritabanlarını mağaza işlemlerinizi içeren tek yer yapmayın. Mağaza işlemlerinize, tıpkı C # veya Java kaynak kodunu işlediğiniz gibi davranılmalıdır. Mağaza proc'larınızın metinsel tanımını kaynak kontrolü. Mağaza proc'larının kaynak kontrollü olamayacağını söyleyen insanlar - bullcrap, sadece ne hakkında konuştuklarını bilmiyorlar.
Uygulamanız için birden fazla sorgu veya görünümden aktarılması veya toplanması gereken veriler gerekiyor. Bunu uygulamadan db'ye yükleyebilirsiniz. Burada bir performans analizi yapmanız gerekir, çünkü a) veritabanı motorları bu şeyleri uygulamada uygulama sunucularından daha verimlidir, but b) uygulama sunucularının yatay olarak ölçeklenmesi (bazen) daha kolaydır.
İnce taneli erişim kontrolü. Db'nizde kartezyen birleştirmeler çalıştıran bazı aptallar istemezsiniz, ama aynı şekilde insanların rastgele SQL ifadeleri yürütmesini de yasaklayamazsınız. Tipik bir çözüm, geliştirme ve UAT ortamlarında rastgele SQL ifadelerine izin verirken, bunları en karmaşık ve üretim ortamlarında yasaklar. Sistest veya üretime dönüştürmesi gereken herhangi bir ifade, hem geliştiriciler hem de dbas tarafından kod gözden geçirilmiş bir mağaza prosedürüne girer.
Bir mağaza prosedüründe SQL ifadesi not için geçerli herhangi bir gereksinim, farklı bir kullanıcı adı/hesap ve bağlantı havuzundan geçer (kullanım çok izlenir ve cesaretini kırılır).
Bunu bir mağaza proc olarak db'de veya uygulama sunucunuzda çalıştırmanız, bir mühendis olarak yapmanız gereken değiş tokuş analizine bağlıdır. Her iki seçenek de bir tür analizle analiz edilmeli ve gerekçelendirilmelidir. Diğer alternatifi "kötü uygulama" olarak suçlayarak şu ya da bu şekilde gitmek, bu sadece topal bir mühendislik görevlisi.
Bu kalıcı bir çözüm olsun ya da olmasın, o anda gözlemlenen kısıtlamalara özgüdür.
Umarım yardımcı olur.
Bunun mantığı, saklı bir yordam katmanına güvenmenin taşınabilirliği sınırlaması ve sizi belirli bir DB'ye bağlamasıdır. Ek bakım maliyetleri de bir sebep olarak gösterilmektedir. Ben de bu konuda yorum yapmak istedim:
(saklı yordamlar) sizi SQL enjeksiyon saldırılarına karşı korur
Aslında sizi koruyan parametreli sorgulamadır, düz metin sql sorgulamasında kolayca yapabilirsiniz.
Saklı proc'ları kabul etmemin bazı nedenleri en iyi uygulama değildir.
Saklı yordamlar size kodun yeniden kullanılmasını ve kapsüllenmesini sağlar (yazılım geliştirmenin iki sütunu),
Evet, ancak diğer çevik tasarım hedeflerine ulaşma pahasına. Bir kere, bakımları daha zordur. Eğer üzerinde çalıştığım proje herhangi bir gösterge ise, büyük olasılıkla aynı işi yapan ve hiçbir faydası olmayan birden fazla, uyumsuz SP ile karşılaşacaksınız.
sizi SQL enjeksiyon saldırılarına karşı korur,
Hayýr. Yapmazlar. Sık sık söylediğini duyduğum gibi, bu fikrin nereden gelebileceğini tahmin bile edemiyorum ve bu doğru değil. Belirli SQL enjeksiyon saldırı türlerini hafifletebilir, ancak ilk etapta parametreli sorgular kullanmıyorsanız, bunun bir önemi yoktur. Hala yapabilirim '; DROP TABLE Hesapları; -
ve aynı zamanda hız konusunda da yardımcı oluyor (DBA, SQL Server 2008'den başlayarak, düzenli SQL sorgularının bile yeterli sayıda çalıştırıldıklarında derlendiğini söyledi).
Ayrıca, hazırlanmış, parametrelenmiş ifadeler kullandığınızda da derlenirler (en azından kullandığım DB'lerin birçoğuyla). Başvurunuz sorguyu yürütmeye başladığında (veya özellikle aynı hazırlanmış sorguyu birden çok kez yürüttüğünüzde), SP öğesinin tamamen tartışmalı olduğunu düşündüğünüz herhangi bir performans avantajı).
Saklı bir yordamı (--- IMHO) kullanmanın yalnızca nedeni, birden çok harmanlanmış kaynaktan alınan karmaşık, çok aşamalı bir sorgu yapmanız gerektiğidir. SP'ler düşük seviyeli karar mantığı içermemelidir ve asla basit bir şekilde basit bir sorguyu kapsamalıdır. Hiçbir fayda ve sadece birçok dezavantajı yoktur.
DBA'nızı dinleyin. Neler olduğunu biliyor.
Çalıştığım şirketlerin üçü de SQL Server ile uygulama mantığı için saklı yordamlar kullandılar. Diğer şeyleri gerçekten görmedim. Ama benim için büyük bir karmaşa. Genellikle çok iyi hata işleme tesisleri veya saklı yordamları olan kod yeniden kullanım tesisleri yoktur.
Diyelim ki kullanmak istediğiniz bir veri kümesini döndüren bir saklı yordamınız var, gelecekteki saklı yordamlarda nasıl kullanabilirsiniz? Bunun için SQL Server'daki mekanizmalar çok iyi değil. YÜRÜTME ... sadece bir ya da iki seviye iç içe geçmeye çalışır (şimdi unuttum). Veya bir çalışma tablosunu önceden tanımlamanız ve işlemin anahtarlanmış olması gerekir. Ya da geçici tabloyu önceden oluşturmanız ve yordamı doldurmanız gerekir. Peki ya iki kişi aynı anda kullanmayı planlamadıkları iki farklı prosedürde geçici tabloyu aynı şeye çağırırsa? Herhangi bir normal programlama dilinde, bir diziyi bir işlevden döndürebilir veya aralarında paylaşılan bir nesneye/global yapıya işaret edebilirsiniz (sadece global bir yapıyı değiştirmek yerine veri yapısını döndüreceğiniz işlevsel diller hariç) ... )
Kodun yeniden kullanımına ne dersiniz? UDF'lere (veya daha da kötüsü alt sorgulara) ortak ifadeler koymaya başlarsanız, kodu durdurmak için yavaşlatacaksınız. Bir sütun için hesaplama yapmak üzere saklı bir yordamı çağıramazsınız (imleç kullanmadığınız sürece sütun değerlerini tek tek geçirin ve ardından tablonuzu/veri kümenizi bir şekilde güncelleyin). Temelde en iyi performansı elde etmek için, bir bakım kabusu olan her yerde ortak ifadeleri kesmeniz/yapıştırmanız gerekir ... Bir programlama dili ile ortak SQL'i oluşturmak için bir işlev oluşturabilir ve daha sonra bina sırasında her yerden çağırabilirsiniz. SQL dizesi. Ardından, formülü ayarlamanız gerekiyorsa, değişikliği tek bir yerde yapabilirsiniz ...
Hata işlemeye ne dersiniz? SQL Server, saklı yordamın hemen yürütülmesini ve hatta bir bağlantı kesilmesini zorlayan birçok hata var. 2005'ten beri try/catch var ama hala yakalanamayan bir takım hatalar var. Ayrıca hata işleme kodunda kod çoğaltma ile aynı şey olur ve gerçekten kolayca istisnaları kolayca geçemez veya çoğu programlama dili kadar kolayca daha yüksek seviyelere kadar kabarcıklar .....
Ayrıca sadece hız. Veri kümeleri üzerindeki birçok işlem SET yönelimli değildir. Satır yönelimli şeyler yapmaya çalışırsanız, ya bir imleç kullanacaksınız ya da bir "imleç" kullanacaksınız (geliştiriciler genellikle her satırı tek tek sorguladığında ve içerikleri imleç gibi @ değişkenlerinde sakladığında. ..Bu genellikle bir FORWARD_ONLY imlecinden daha yavaş olsa da). SQL Server 2000 ile onu öldürmeden önce 1 saat boyunca çalışan bir şey vardı. Bu kodu Perl'de yeniden yazdım ve 20 dakika içinde bitti. C'den 20-80x daha yavaş bir betik dili performansta SQL'i içtiğinde, SQL'de kesinlikle satır yazma işlemleri yapmazsınız.
Şimdi SQL Server CLR entegrasyonu var ve CLR saklı yordamları kullanırsanız bu sorunların birçoğu gider. Ancak birçok DBA, güvenlik sorunları nedeniyle .NET programlarının nasıl yazılacağını veya CLR'nin nasıl kapatılacağını bilmiyor ve Transact SQL'e bağlı kalıyor ... Ayrıca CLR'lerde bile birden çok prosedür arasında verimli bir şekilde veri paylaşma konusunda sorunlarınız var. .
Ayrıca genel olarak ölçeklendirilmesi en zor şey veritabanıdır. Tüm iş mantığınız veritabanındaysa, veritabanı çok yavaşladığında sorunlarınız olacaktır. Bir iş katmanınız varsa, performansı artırmak için daha fazla önbellek ve daha fazla iş sunucusu ekleyebilirsiniz. Geleneksel olarak windows/linux kurmak 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 şimdi daha fazla kümeleme desteğine sahip, aslında aslında hiç yoktu. Bu yüzden çok paranız varsa, birden fazla salt okunur kopya oluşturmak için kümeleme ekleyebilir veya hatta bazı günlük gönderim yapabilirsiniz. Ama genel olarak bu, sadece önbellek veya başka bir şeyin arkasında bir yazı yazmaktan daha pahalıya mal olacak.
Ayrıca Transact-SQL tesislerine bakın. String Manipülasyon? Java String Class/Tokenizer/Scanner/Regex sınıflarını her gün alacağım. Karma Tablolar/Bağlantılı Listeler/Vb. Java Koleksiyon çerçeveleri, vb ... Ve aynı .NET için ... Hem C # ve Java Transact SQL'den çok daha gelişmiş dillerdir ... Transact-SQL ile heck kodlama beni kıskanıyor C ...
Ayrıca saklı yordamlar, büyük bir veri kümesiyle çalışmak ve iş katmanına geri dönmeden önce küçültmek için birden fazla sorgu/kriter uygulamak için daha etkilidir. Bir grup büyük veri kümesini istemci uygulamasına göndermeniz ve istemcideki verileri parçalamanız gerekiyorsa, sunucudaki tüm işleri yapmaktan çok daha verimsiz olacaktır.
Ayrıca saklı yordamlar güvenlik için iyidir. Temel tablolara tüm erişimi kesebilir ve yalnızca saklı yordamlar aracılığıyla erişime izin verebilirsiniz. XML gibi bazı modern tekniklerle toplu güncellemeler yapan prosedürleri saklayabilirsiniz. Daha sonra güvenli/doğru oldukları sürece tüm erişim saklı yordamlar aracılığıyla denetlenir ve veriler daha fazla bütünlüğe sahip olabilir.
SQL enjeksiyon argümanı, programlama dili tarafında sorguları parametreleştirdiğimiz için artık çok fazla geçerli değil. Ayrıca parametreli sorgulardan önce bile küçük bir değiştirme ("'", "' '") çoğu zaman da çalıştı (yine de istediğinizi elde etmek için dizenin sonundan geçmek için hala kullanmak için hileler olsa da).
Genel olarak SQL ve Transact SQL'in verileri sorgulamak/güncellemek için harika diller olduğunu düşünüyorum. Ama her türlü mantığı kodlamak için, dize manipülasyonu (ya da heck dosya manipülasyonu yapmak ... xp_cmdshell ile neler yapabileceğinize şaşıracaksınız ....) lütfen hayır. Çoğunlukla saklı yordamlar kullanmayan gelecekteki bir yer bulmayı umuyorum. Kodun sürdürülebilirliği açısından bir kabus. Ayrıca platformlar arasında geçiş yapmak istiyorsanız ne olur (Oracle/DB2/Sybase/Sql Server/vb. İçin ödeme yaptıysanız. Size yardımcı olabilecek her özel uzantıyı kullanarak bunlardan alabileceğiniz her şeyi alabilirsiniz. ..).
Ayrıca şaşırtıcı bir şekilde iş mantığı aynı değildir. İdeal dünyada, tüm mantığı saklı yordamlara koyacak ve bunu uygulamalar arasında paylaşacaksınız. Ancak çoğu zaman mantık uygulamalara bağlı olarak değişir ve saklı prosedürleriniz, insanların değişmekten korktuğu ve tüm sonuçlarını anlamadığı aşırı karmaşık monolitlere dönüşür. İyi bir nesne yönelimli dil 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.
Birkaç yıl önce Big Five'lardan birinde çalıştığımda bu resmi çizgiydi. Bunun mantığı, SP'lerin belirli uygulamalara (PL/SQL vs T/SQL vs ...) bağlı olması nedeniyle gereksiz yere teknoloji seçeneklerini sınırlamalarıdır.
Bir büyük sistemin T/SQL'den PL/SQL'e geçişini yaşadıktan sonra, argümanı anlayabiliyorum. Bence biraz canard - kaç yer gerçekten bir heves bir veritabanından diğerine taşımak?
Saklı yordamları sunucuda nasıl sürümlendirirsiniz?
Saklı yordamları sunucuya sürüm denetiminden yeniden dağıtırsanız, saklı yürütme planını uçurur.
Saklı yordamlar doğrudan sunucuda değiştirilemez, aksi takdirde _right'ın gerçekte neyin çalıştığını nasıl bilebilirsiniz? Değilse, dağıtım aracının saklı yordamları veritabanına yazmak için erişime ihtiyacı vardır. Her derlemede dağıtmanız gerekir (yürütme planının farklı olması gerekebilir)
Saklı yordamlar taşınabilir olmasa da, genel olarak SQL de değildir (Oracle tarih işleme - uggghhh).
Dolayısıyla, taşınabilirlik istiyorsanız, dahili bir veri erişim API'sı oluşturun. Buna fonksiyon çağrıları gibi çağırabilirsiniz ve dahili olarak parametreli sorgularla dilediğiniz dil üzerinde inşa edebilirsiniz ve sürüm kontrollü olabilir.
Bu öğrendiğim her şeye aykırı.
Daha fazla çıkmanız gerekebilir. Ciddi bir şekilde, saklanan procs en az 10 yıldır düşüşte. N-katman, istemci sunucunun yerini aldığından beri. Bu düşüş yalnızca OO Java, C #, Python vb. Diller) benimsenerek hızlandırıldı.
Bu, kayıtlı protestoların hala savunucuları ve savunucuları olmadığı anlamına gelmez - ancak bu uzun süren bir tartışma ve tartışmadır. Bu yeni değil ve muhtemelen bir süredir devam edecek; IMO, kayıtlı procların muhalifleri açıkça kazanıyor.
Saklı yordamlar size kodun yeniden kullanılmasını ve kapsüllenmesini sağlar (yazılım geliştirmenin iki sütunu)
Çok doğru. Ancak, düzgün bir şekilde tasarlanmış OO katmanı).
güvenlik (tek bir depolanmış proc için izinler verebilir/iptal edebilirsiniz)
Bunu yapabilirken, ciddi sınırlamalar nedeniyle çok azı bunu yapıyor. DB düzeyindeki güvenlik, bağlama duyarlı kararlar verecek kadar ayrıntılı değildir. Performans ve yönetim yükü nedeniyle, kullanıcı başına bağlantılara sahip olmak da olağandışıdır - bu nedenle uygulama kodunuzda yine de bir miktar yetkilendirmeye ihtiyacınız vardır. Rol tabanlı oturum açma bilgilerini kullanabilirsiniz, ancak bunları yeni roller için oluşturmanız, hangi rolü yürüttüğünüzü korumanız, "sistem düzeyi" günlüğe kaydetme gibi çalışmak için bağlantıları değiştirmeniz gerekir. Ve sonunda, uygulamanız sahibi - DB ile bağlantınız da öyle.
sizi SQL enjeksiyon saldırılarına karşı korur
Parametreli sorgular yapmaktan daha fazlası yok. Hangi gerekir yine de yapıyor.
ve aynı zamanda hız konusunda da yardımcı oluyor (DBA, SQL Server 2008'den başlayarak, düzenli SQL sorgularının bile yeterli sayıda çalıştırıldıklarında derlendiğini söyledi).
Ben MSSQL 7 veya 2000'de başladı düşünüyorum. Saklı proc vs satır içi SQL performans üzerinde bir sürü tartışmalar, ölçümler ve yanlış bilgi oldu - ben hepsini YAGNI altında götürün. Ve ihtiyacınız varsa test edin.
Agile yazılım geliştirme metodolojisini kullanarak karmaşık bir uygulama geliştiriyoruz. Depolanmış proc'ları kullanmak istememelerinin iyi nedenlerini düşünen var mı?
Ben istiyorum için birçok neden düşünemiyorum. Java/C #/herhangi bir 3. GL dil, kapsülleme, yeniden kullanma ve ferahlanabilirlik vb. T-SQL'den çok daha yeteneklidir. Çoğu, yarı iyi bir ORM verildiğinde ücretsizdir.
Ayrıca, "gerektiği gibi dağıtmak, ama daha fazla değil" tavsiye verildi - Bence bu gün ispat yükü SP savunucuları. SQL, OO'dan daha kolaydır ve dükkan, OO'dan daha iyi T-SQL geliştiricilerine sahiptir.Veya, DBA veritabanı katmanında durur ve depolanan procs, dev ve DBA arasındaki arabirimdir. ürün ve depolanan procs kullanıcı özelleştirilebilir.Bunun gibi bazı hususlar yok, bu günlerde herhangi bir Agile SW projesi için varsayılan ORM olacağını düşünüyorum.
Yukarıdaki tüm durumlar göz önüne alındığında, bir tane daha eklemek istiyorum. SP seçimi, insanların seçimine de bağlı olabilir.
İnsanlar SP ve ben böyle SP korumak ve hata ayıklamak için çok karmaşık olduğuna inanıyorum. arkasındaki kodda hata ayıklama problemi (diyelim ki dil kısmı) SP'den çok daha kolaydır.
SP yalnızca basit işlemler için kullanılmalıdır. Bu benim seçimim.
Saklı proc ile bazı sorunları ve sorunları ele almak istiyorum. Onları LedgerSMB ile yaygın olarak kullanıyoruz ve kuralımız çok özel bir uzantıyla, "bir sorgu ise, bunu saklı bir proc yapın."
Bunu yapmamızın nedeni, diller arası sorgu kullanımının kolaylaştırılmasıydı. Bunu dürüstçe yapmanın daha iyi bir yolu yok.
Sonunda soru her zaman ayrıntılarda. İyi kullanılmış, saklı prosedürler işleri çok daha kolay hale getirir ve kötü kullanılan şeyleri daha zor hale getirir.
Böylece con tarafına.
Geleneksel olarak kullanıldığı gibi, saklı prosedürler kırılgandır. Tek başına kullanıldıklarında, çağrı sözdiziminin değiştirilmesinden başka hiçbir nedenle beklemediğiniz yerlerde kodunuza hata ekleme imkanı yaratırlar. Tek başına kullanıldığında bu bir problemdir. Katmanlar arasında çok fazla uyum vardır ve bu da sorunlara neden olur.
Evet, herhangi bir dinamik sql yapıyorsa, intra-sproc sql enjeksiyonuna sahip olmak mümkündür. Bu alana aşırı güvenmek kötü bir şeydir ve sonuç olarak bu alanda güvenlik konusunda önemli bir deneyime sahip olmak gerekir.
Arabirimlerdeki değişiklikler yukarıdaki # 1 nedenden dolayı saklı yordamlarla biraz sorunludur, ancak çok sayıda istemci uygulaması söz konusu olduğunda bu çok büyük bir kabus haline gelebilir.
Yukarıdakileri inkar etmek oldukça zordur. Onlar olur. Herkes, SP yanlısı ve SP karşıtı muhtemelen bunlarla ilgili korku hikayeleri yaşamıştır. Sorunlar çözülemez ancak bunlara dikkat etmezseniz bunları çözemezsiniz (LedgerSMB'de dinamik olarak SP çağrıları arama zamanında kaçınarak, Sadece PostgreSQL varken, diğer db'ler için benzer bir şey yapılabilir).
Pozitif üzerinde. Yukarıdaki sorunları çözebileceğinizi varsayarsak, şunları elde edersiniz:
Ayarlanmış işlemlerde daha fazla netlik olasılığı. Sorgunuz çok büyük veya çok esnekse bu özellikle doğrudur. Bu aynı zamanda gelişmiş test edilebilirliğe yol açar.
Zaten bu alanda çalışan bir servis bulucu varsa, uygulama geliştirici db endişeleri ve tam tersi serbest çünkü saklı yordamlar gelişme hızını hızlandırmak buluyorum. Bunun doğru yapmakta bazı zorlukları var ama bunu yapmak o kadar da zor değil.
Sorgu yeniden kullanımı.
Oh ve bir SP'de neredeyse hiç yapmamanız gereken birkaç şey:
işlemsel olmayan mantık. Siparişin gönderildiği e-postayı gönderdiniz ancak işlem geri alındı ... veya şimdi e-posta sunucusunun çevrimiçi olması için devam etmeyi bekliyorsunuz .... veya daha kötüsü, yalnızca e-posta sunucusu ....
küçük sorgular bir sürü birlikte, sinirli prosedürel mantık serpilir ....
Veritabanı markalarını değiştirmek ve aynı saklı yordamları kullanmak çok zordur.
Ekibinizin de bir DBA'sı yok ve hiç kimsenin sql ile ilgisi olmak istemiyor.
Bu bir programcı v DBA pissing yarışmasından başka bir şey değildir.
Kimin için çalışıyorsun?
Bu sorunun cevabı kim tarafından istihdam edildiğinize, danışmanlık firmasına veya şirketin kendisine bağlı olabilir. Bir şirket için en iyi olan şey genellikle bir danışmanlık firması veya diğer yazılım satıcıları için en iyi yöntem değildir. Örneğin. Akıllı bir şirket, rakiplerine göre kalıcı bir avantaj elde etmek istemektedir. Buna karşılık bir yazılım satıcısı, aynı çözümü belirli bir sektördeki tüm işletmeler için en düşük maliyetle ele almak istiyor. Eğer bu konuda başarılı olurlarsa, müşteri için net bir rekabet avantajı olmayacaktır.
Bu özel durumda, uygulamalar gelir ve gider, ancak çok sık, kurumsal veritabanı sonsuza dek yaşar. RDBMS'nin yaptığı ilk şeylerden biri, gereksiz verilerin veritabanına girmesini engellemektir. Bu, saklı yordamları içerebilir. Mantık iyi bir mantıksa ve yıldan yıla değişme olasılığı düşükse, veritabanını kullanmak için hangi uygulama yazılırsa yazılsın, neden veritabanında olmamalıdır? Yıllar sonra birisinin veritabanından sormak istediği bir sorusu olacak ve önemsiz DB'ye girmesi engellenirse bu soruya cevap verilecektir.
Belki de bunun DBA'nızın bir danışmanlık firması için çalışmasıyla bir ilgisi vardır. Kodlarını ne kadar taşınabilir hale getirebilirlerse, kodu istemciden istemciye tekrar kullanabilirler. Uygulamalarında daha fazla mantık kurabilirlerse, şirket satıcıya o kadar çok bağlı kalır. Süreçte büyük bir karmaşa bırakırlarsa, temizlemek için ödeme alırlar veya karışıklığı bir daha asla görmezler. Her iki durumda da bu onlar için bir kazanç.
Çitin her iki tarafında (çok) daha fazla tartışma için kodlama dehşeti adresindeki tartışmayı okuyun. FWIW SP'leri savunanların yanına yaslanıyorum.
Yalnız programlama, dayanamıyorum saklı yordamlar yazma.
Öncelikle MySQL kullanıyorum. Daha önce PostGreSQL gibi nesne yönelimli veritabanlarını kullanmadım, ancak MySQL'deki SP'lerle yapabileceğim şey tablo yapısını biraz uzakta soyut. SP'ler, altındaki veritabanı değişiyor değişse bile, girişleri ve çıkışları değişmeyecek olan bu ilkel eylemleri tasarlamama izin veriyor.
Yani,
logIn adında bir prosedürüm var. Giriş yaptığınızda her zaman
username ve
password iletirsiniz. Geri gönderilen sonuç
userId tamsayısıdır.
logIn bir saklı yordam olduğunda, şimdi ilk oturum açma ile aynı zamanda gerçekleşen oturum açma yapılacak ek iş ekleyebilirsiniz. Saklı yordam gömülü mantık ile SQL ifadeleri bir dizi bulmak - yazmak daha kolay (arama ortamı FETCH) -> (sonuç almak) -> (arama ortamı FETCH) serisinden mantık sunucusu tarafınızı yazarken yapmanız gerekir.
İş mantığının, farklı programlama dilleri kullanarak farklı katmanlar arasında bölünmesi her zaman bir sorun kaynağıdır. Dünyalar arasında geçiş yapmanız gerektiğinde bir hatayı izlemek veya bir değişikliği uygulamak çok daha zordur.
Bununla birlikte, veritabanında yaşayan PL/SQL paketlerine all iş mantığını koyarak oldukça iyi iş yapan şirketleri biliyorum. Bunlar çok büyük uygulamalar değil, ama önemsiz de değil; 20K-100K LOC deyin. (PL/SQL bu tür bir sistem için T-SQL'den daha uygundur, bu yüzden sadece T-SQL'i biliyorsanız, muhtemelen şimdi inkar etmek için başınızı sallayın ...)
Bu henüz belirtilmeyen başka bir nokta:
Kod oluşturma araçları ve tersine mühendislik araçları, saklı yordamlarla gerçekten başa çıkamaz. Araç genellikle proc'un ne yaptığını söyleyemez. Proc bir sonuç kümesi döndürüyor mu? Birkaç sonuç kümesi? Sonuç kümelerini birkaç tablodan ve geçici tablolardan alıyor mu? Proc sadece kapsüllenmiş bir güncelleme bildirimi midir ve hiçbir şey döndürmez mi? Bir sonuç kümesi, bir dönüş değeri ve bazı "konsol çıktısı" döndürüyor mu?
Dolayısıyla, otomatik olarak bir veri aktarım nesnesi DTO ve DAO katmanı oluşturmak için bir araç kullanmak istiyorsanız (liferay'ın "hizmet oluşturucusu" gibi), bunu kolayca yapamazsınız.
Ayrıca, Hibernate gibi ORM'ler veri kaynağı SP olduğunda gerçekten düzgün çalışamaz. Veri erişimi en iyi ihtimalle salt okunurdur.
IMO bağlıdır. Saklı yordamların yerleri vardır, ancak bunlar en iyi uygulama değildir ve ne pahasına olursa olsun kaçınılması gereken bir şey değildir. Akıllı bir geliştirici, belirli bir durumu doğru bir şekilde nasıl değerlendireceğini ve saklı bir yordamın cevap olup olmadığını nasıl belirleyeceğini bilir. Şahsen ben belki önceden tanımlanmış raporlar ya da benzeri dışında saklı prosedürler yerine bir tür bir ORM (hatta ham Linq to Sql gibi temel bir) kullanma hayranıyım ama yine de gerçekten duruma göre.
Mark'ın, topluluğun uzun süredir saklı prosedürlerden gerçekten uzaklaşmakta olduğunu kabul ediyorum. Orijinal posterin neden SP'leri kullanmak istediğimizi ortaya koyduğu noktaların birçoğu geçerliyken, bir süredir geçerliydi ve başka bir posterin dediği gibi çevre değişti. Örneğin, SP'leri 'gün içinde' kullanmanın bir argümanının elde edilen performans kazanımları olduğunu hatırlıyorum çünkü kodumuzdaki dinamik SQL her yürütmede 'yeniden derlenecek' iken yürütme planları 'önceden derlenmiş'. Büyük veritabanları değiştiği, geliştiği, uyarlandığı vb. Nedeniyle artık durum böyle değil.
Bununla birlikte, mevcut projemde SP'ler kullanıyoruz. Bunun nedeni, eski uygulamaları destekleyen mevcut bir veritabanının üzerine yeni uygulamalar oluşturmamızdır. Sonuç olarak, eski uygulamaları kapatana kadar şema değişiklikleri yapmak çok zordur. Yeni uygulamalarımızı uygulama için gerekli davranış ve kurallara göre tasarlamaya ve SP'leri veritabanı ile olmasını istediğimiz şekilde geçici olarak arabirim oluşturmak ve SP'lerin mevcut SQL'e uyum sağlamasına izin vermek için bilinçli bir karar verdik . Bu, SP'nin uygulama kodunda değişiklik yapılmasına gerek kalmadan veritabanı düzeyinde değişiklik yapmayı kolaylaştırdığı önceki bir posterin noktasına gider. SP'leri Adaptör modelinin bir uygulaması olarak kullanmak kesinlikle benim için anlamlıdır (özellikle şu anki projem göz önüne alındığında) ve bugün kullanımları için gerçekten görebildiğim tek argüman olabilir.
Fwiw, niyetimiz şema güncellendiğinde SP'leri kaldırmaktır. Ancak, kurumsal gelişimdeki diğer her şeyde olduğu gibi, bunun gerçekleşip gerçekleşmediğini göreceğiz! [sırıtış]
Ayrıca saklı yordamlar sunucuda cpu zaman kullandığını belirtmek istiyorum. Çok değil ama bazıları. Çalışma prosedüründe yapılan çalışmaların bazıları uygulamada yapılabilir. Uygulama katmanını ölçeklendirmek veri katmanından daha kolaydır.
Saklı yordamları kullanmayı nasıl önereceğime dair kısa bir genel bakış yapmak istedim. Onların kötü bir uygulama olduğunu düşünmüyorum ve diğerleri gibi söyledikleri gibi uygun durumlarda kullanılmaları gerekir.
Farklı uygulamalar için yazma prosedürlerinin işlevsellikte kafa karıştırıcı hale gelebileceği ve uygulamanın iş mantığını ayırabileceği ve veritabanının daha dağınık ve kısıtlayıcı hale gelebileceği sorunları görebiliyorum.
Bu nedenle, veritabanına özgü ilişkisel veri odaklı görevlerde saklı bir yordam kullanırdım. Başka bir deyişle, herhangi bir uygulama için verilerle tutarlı olan veritabanı işlemleri için kullanılan bir mantık varsa, verileri tutarlı bir şekilde saklamak için (mantıklı) saklı yordam kullanılabilir. Bunun iyi örneklerini düşünüyorum: tutarlı günlük tutma, tutarlı bakım, hassas bilgilerle çalışma, vb.
Diğer görevler, veritabanının güçlü veri modelini takip eden uygulamanın ihtiyaçlarına uyacak şekilde verileri manipüle eder, bence iş mantığını içeren başka bir katmanda saklanmalıdır. Kısacası tutarlılık için veritabanına özgü veri manipülasyonu, tutarlılığın veritabanı bütünlüğü şema modelini geçecek şekilde saklandığı yordamları kullanabilir.