Ne zaman ORM kullanılmaz ve saklı prosedürler tercih edilir?

13

PetaPoco mikro-ORM kullanıyorum. ORM araçlarını kullanarak veritabanlarıyla çalışmak gerçekten çok kolay ve güvenlidir, ancak nefret ettiğim tek şey ekstra koddur. Kodun çoğunu veritabanının içine koyar ve daha iyi işlemek için inşa edilen Saklı Yordamlar, Tetikleyiciler vb.Gibi tüm RDBMS özelliklerini kullanırdım.

ORM'yi Saklı Yordamlar / Tetikleyiciler üzerinde ne zaman kullanmamayı bilmek istiyorum.

orm rdbms stored-procedures

— RPK
kaynak

6

Şahsen tetikleyiciler ile benim sorunum (özellikle, saklı yordamlar için geçerli değildir) onlar DB "veri nasıl manipüle" ne "iş eylemi" oldu "tahmin" için çalışıyoruz. "MAKALELER" tablosundaki FİYAT sütununu değiştirirseniz, bunun nedenini gerçekten bilmiyorsunuzdur . Kullanıcı yanlış yazılmış bir değeri mi düzeltiyor? Bu bir not mu? Sadece bir gün süren özel bir teklif mi? Tetikleyiciler bunların hepsini tahmin etmelidir.

— Joachim Sauer

16

ORM'ler (Nesne-ilişkisel eşleme) Saklı Yordamlar ile birbirini dışlamaz. Çoğu ORM, saklı yordamları kullanabilir. İsterseniz çoğu ORM, Saklı Yordamlar oluşturur. Yani mesele ya da değil.

ORM'ler kabul edilemez SQL üretebilir (performans açısından) ve bazen bu SQL'i el yapımı SQL ile geçersiz kılmak isteyebilirsiniz. Bunu yapmanın yollarından biri SP'leri kullanmaktır (saklı yordamlar).

DotNet'te aşağıdaki durumlarda saklı yordamları kullanmayın:

Saklı yordamlara aşina değilseniz (durumunuz değil, tamlık için dahil edilmiştir).
Projenize bir karmaşıklık ve aydınlatıcı katmanı tanıtmak istemiyorsanız.
Farklı veritabanlarıyla çalışacak veya birkaç veritabanı sunucusunda çoğaltılması gereken bir uygulama oluşturuyorsunuz (bu son kısıtlama yalnızca bazı veritabanları için geçerli olabilir).

Tetikleyicilerin ORM'lerle karşılaştırılmaması gerektiğini unutmayın. Tetikleyiciler, uygulama kodunuzda daha iyi olmayan işlevler yapar (veritabanlarında verileri günlüğe kaydetme veya senkronize etme gibi).

Bazı insanlar, güvenlik (örneğin SQL enjeksiyonunu önlemek için) gibi farklı nedenlerle ve talep edilen hızları için SQL'de Saklı Yordamların kodda kullanılmasını tercih eder. Ancak, bu biraz tartışmalıdır ve ayrıntılı tartışmaya ihtiyaç vardır.

ORM'niz Saklı Yordamlar oluşturamıyorsa ve büyük bir sistem yazmanız gerekiyorsa, davanıza bağlı olarak ekstra el kodlamasının ağırlığını almanız gerekir.

— Şans yok
kaynak

2

Güvenlik argümanı SQL enjeksiyonu ile ilgili değil, daha ziyade izinler ile ilgili olduğuna inanıyorum (yani veritabanına erişimi olan kullanıcılar için belirli bir saklı yordamın izinlerini yönetmek, ancak tablolar, sütunlar ve satırlar daha zor veya imkansızdır). Yine de, güvenlik argümanı tartışmalıdır.

— Arseni Mourzenko

@MainMa, yorumunuz için teşekkürler. Anladığım kadarıyla, SP'lerin kullanılması

— NoChance

2

Saklı yordamların sql enjeksiyon saldırılarına açıklığı üzerinde neredeyse hiçbir etkisi yoktur. Eski efsaneler zor ölüyor.

— Rig

@ Rig 1, yorumunuz için teşekkür ederim, bunun hakkında ne düşündüğünüz hakkında daha fazla bilgi edinmek istiyorum. Benim anlayışım bu metinden geliyor (en azından): "Saklı yordamları ve parametreli komutları kullanarak, dinamik SQL'den kaçınarak ve tüm kullanıcılar için izinleri kısıtlayarak SQL Server enjeksiyon saldırılarını engelleyebilirsiniz." msdn.microsoft.com/en-us/library/bb669057.aspx adresinde

— NoChance

@EmmadKareem Parametreli sql, güvenli hale getirmede büyük bir adımdır. Sanırım bu adam makul bir dava yapıyor palpapers.plynt.com/issues/2006Haziran/injection-stored-procedures . Üzerinde bir arama "Saklı Yordam SQL Enjeksiyon" çok hit olacaktır. Girdilerinizi sterilize etmek her zaman iyidir ve birçok platform bunu makul bir şekilde yapmak için yerleşik bir yol sağlar.

— Rig

13

ORM'ler genellikle veritabanının ORM'ye hizmet etmek için var olduğunu varsayar. Ancak genellikle veritabanı, vurmak için birden fazla dilde yazılmış yüzlerce ve yüzlerce uygulamaya sahip olabilecek şirkete hizmet etmek için vardır.

Ancak, saklı yordamı çağıramayan bir ORM kullanıyorsanız, yalnızca "ORM ve Saklı Yordamlar" örneğidir. Aksi takdirde, iş mantığının nereye kodlanacağına karar verme durumudur.

İş mantığını her nereye kodlarsanız yapın, görevi hangi uygulamanın değişiklik yaptığına bakılmaksızın veritabanının bir tutarlı durumdan başka bir tutarlı duruma değiştiğinden emin olmaktır . Yani gerçekten sadece iki pratik seçeneğiniz var - bunu veritabanında bir kez kodlayın veya "geçilemez" bir veri erişim katmanında bir kez kodlayın.

"Geçilemez" bir DAL kullanıyorsanız, dbms komut satırı arabirimine dikkat edin.

— Mike Sherrill 'Kedi Hatırlama'
kaynak

4

Eski SP'lerin ve tetikleyicilerin mevcut eski uygulamalar nedeniyle yeni uygulamalarla kullanılması gereken birden fazla durumla karşılaştım. Avantajı, bu iş mantığının tek bir yerde muhafaza edilmesi gerektiğidir.

— jfrankcarr

Kesinlikle "hepsine hizmet etmek için bir veritabanı" kullanıldığını inkar etmiyorum, ancak özellikle birden fazla uygulama saklanan procs kendi sürümlerini korumak gerektiğinde, bakım saf cehenneme dönüştüğü için çoğunlukla geçmişte kaldı. Sahip olduğu uygulamaya hizmet etmek için veritabanının bulunması, uygulamalar ve hizmetler arasında daha gevşek bağlantıyı zorladığı için çok daha modern bir yaklaşımdır.

— flater

-1

Basit sorgu -> ORM

Karmaşık sorgu -> Saklı Yordam

— Karanlık gece
kaynak

3

Bir kompleks basit bir Sorgudan nereden ayrılır,

— Bağımsız

-2

Tetik, kaydın değişmezi olarak kullanılmalı veya hayati ticari kurallardan (IMHO) oluşmalıdır.

Ormların sorunları:

Tablolar için izinleri ayarlamanız gerekir, "İşlem" başına değil (SP demek)
Çözümünüzün mantığını değiştirmek için uygulamanızın içindeki kodu değiştirmeniz ve ardından istemciler için ağ üzerinden yeniden dağıtmanız gerekir

— Yuriy Vikulov
kaynak

-5

Katılmıyorum. ORM sorgusu yalnızca ORM'yi SQL'den daha iyi biliyorsanız daha basittir. ORM çok daha fazla kodla sonuçlanır, IMO'nun bakımı çok daha zordur. ORM'den yararlanan tek kişi ORM'yi satan şirketin hissedarlarıdır (örn. Microsoft).

— fantom
kaynak

1

bu cevapta ifade edilen görüşün ne referanslarla ne de deneyimle desteklenmediğine üzücü. Sonuç olarak, saklı yordamların yalnızca DB satıcılarına fayda sağladığı gibi "ters" bir iddia üzerine rastlayabilen bir okuyucu için işe yaramaz olacaktır . Rehberlik neden bir fark yapar Gerçek Sorular Cevaplar Var durumları: "Gerçek soru var cevapları , değil öğeleri veya fikirleri veya görüşler ... "

— tatarcık