Selam arkadaşlar. ORM kullanımının DB de trigger ve procedure kullanımına göre avantaj ve dezavantajları nelerdir?

Performansı ne şekilde etkiler?

Procedure ve Trigger kullanımı bir nevi orta katmanında DB tarafına taşımaz mı?

soruldu: 05 Mar '13, 01:43

Alp's gravatar image

Alp
873304447
cevap kabul oranı: 18%

değiştirildi: 06 Mar '13, 15:58

Bir link paylaşayım ve sizin de yorumlarınızı bekliyorum. http://www.mustafayalcin.net.tr/orm-nedir-ve-ne-zaman-kullanmali-veya-kullanmamaliyiz.html

(05 Mar '13, 01:48) Alp Alp's gravatar image
1

genel olarak tüm dillerde orm, platform bağımszlığı sağlar. Yani siz işlemlerinizi windows phone a göre yaptınız diyelim. Daha sonra ise windows 8 e taşımak istediniz. Bu noktada ise orm nin faydası ortaya çıkıyor. Ancak hangi durumda hangi orm çatısı tercih edilmelidir orası biraz muamma :)

(05 Mar '13, 01:52) emax_64 emax_64's gravatar image

En büyük avantajı arka planda veritabanı servisinizin değişmesinden, uygulamanızın etkilenmemesidir. Yazılımcı için crud işlemlerini kolaylaştırması.

(05 Mar '13, 02:39) Turgay Can Turgay%20Can's gravatar image

10

Bir çok soru sormuşsunuz, hepsine cevap veremeyeceğim ama sadece başlıktaki soruya cevap vereyim.

PERFORMANS:

Temel CRUD(Create, Read, Update, Delete) işlemleri için performans neredeyse aynıdır, bu açıdan performans önemsiz kalıyor, bundan dolayıda ORM araçlarının CRUD işlemleri için kullanılması proje geliştirme hızını çok büyük oranda artırır . Büyük verilerin, kompleks SQL kodları ile raporlanması, istatistikleri, analizleri, filtrelenmesi veya arama yapılması gibi konularda performans sorunları gözle görülebilir bir sıkıntıya dönüşebilir. Bu noktada, ORM araçlarının profesyonel özelliklerinin bilinmesi durumunda (lazy loading, eager loading, caching, ...) bu açık ta biraz daha kapanacaktır.

GELİŞTİRME SÜRECİ:

ORM araçlarının en büyük gücü ve avantajı hızlı geliştirme(RAPID Development) olanağı sunmasıdır. Ayrıca ORM araçlarının bünyesinde bulunan bir çok hazır fonksiyonlar ve farklı özellikler sayesinde "az kod çok iş" yapabilme olanağı sağlıyor. Bazen (hatta çoğu zaman) iyi derecede SQL bilmek gerekebilir. Bu da yazılım geliştirme sürecinde hız açısından dezavantaj olabilir. SQL kullanmanın buradaki avantajı ise ekip çalışmasında veritabanı uzmanlarının SQL sorgularına müdahalesinin kolaylığıdır.

BAKIM:

ORM araçları veritabanını nesneye yönelik programlama yöntemleri ile yönettiği için nesneler üzerinde daha fazla kontrol imkanı da sunar. Veritabanından gelen veriler direk olarak (aslında gelen veri diye birşey yok zaten nesnelerimiz veritabanı tablolarını temsil ediyor) bir veri yapısı olarak gelir bundan dolayıda veri dönüşümleri ile uğraşmaktanda kurtulmuş oluruz. Ayrıca ORM araçları farklı veritabanları ile çalışabilir (MSSQL, ORACLE, MYSQL). Daha test edilebilir bir yapı da sunar.

ESNEKLİK:

SQL kodları daha esnek bir yapı sunar. Çünkü farklı istekler için farklı SQL sorguları yazılabilir. SQL kodlarına müdahale edilebilir. Ama ORM araçlarının ürettiği SQL kodlarına müdahale edemezsiniz. SQL kullanmanın buradaki dez-avantajı, proje içerisinden sorgulara çok müdahale edilememesidir.

NOT: Her iki yöntemide (SQL taraflı çalışmak(SP, Trigger, Funcs, Views, ...), ORM araçları ile çalışmak) aynı projede kullanabilirsiniz. Hatta bazı durumlarda bu zorunluluk bile olabilir.

permanent link

cevaplandı: 05 Mar '13, 02:13

AliR%C4%B1za%20Ad%C4%B1yah%C5%9Fi's gravatar image

AliRıza Adıyahşi ♦
7.9k146288
cevap kabul oranı: 44%

değiştirildi: 05 Mar '13, 07:09

Açıkçası ORM ve SQL'ı neden birbirinden tamamen ayırıyorsunuz anlamadım. Örnek olarak şu anda üzerinde çalıştığım uygulamada ikisinin ne akdarda güzel beraber çalıştıklarnı göstereyim.

Uygulamamda "Sales" adında bir Entity class'ım var. Burada adından da anlaşılacağı üzere "Satış bilgileri" bulunmakta.

Ayrıca zaman zaman tek tek "Sales" nesneleri yerine SalesSummaries isimli bir class'ım daha var (bu bir entity değil). Ben çok kolay bir şekilde tek satırda bunu yapabiliyorum:

List<salessummaries> summaries = Sales.find("select new models.SalesSummaries(sum(sales.tutar),sales.productName) from Sales as sale group by sales.productName").fetch();

sadece sql kullanıyor olsak, sanırım bu işlemi yapmak bir satırdan ve birkaç saniyeden daha uzun sürecekti diye düşünüyorum :)

permanent link

cevaplandı: 05 Mar '13, 07:18

dreampowder's gravatar image

dreampowder
3.3k112849
cevap kabul oranı: 23%

Burda sadece java tarafında yazılan SQL'lerden bahsetmiyoruz degil mi? Yani demek istedigim Function,Procedure ve Triggerlar ile çalışmak orta katmanı DB ye taşımaz mı? burda bunların bir iş akışı oluşturmasıda söz konusu. Ayrıca benim aldıgım revizyonlarda kararlı olmuyacaktır.DB de degişen herhangi bir function benim kodumu kırılgan bir hale getirmez mi ?

(06 Mar '13, 01:40) Alp Alp's gravatar image

ORM'in bir güzelliğide trigger ve procedure ları uygulama kodu seviyesinde oluşturuyor olmamız, yani ORM kullanılan bir uygulamada SQL ile herhangi bir işimiz olmuyor, herşey uygulama kodu içerisinde.

Yine Hibernate'ten örnek vermek gerekirse, Trigger işlemleri için entitymizin içerisinde "onSave, onDelete, vs.." gibi "data interceptor" metodları ekleyebliiriz..

Procedure lar için ise yine aynı şekilde kod seviyesinde,HQL ve benzeri yöntemlerle bildiğimiz java metodu şeklinde uygulayabiliyoruz.

(06 Mar '13, 02:13) dreampowder dreampowder's gravatar image

Tutarlılık konusunda, açıkçası modelinizde çok köklü bir değişiklik yapmadığınız sürece herhangi bir sıkıntı yaşamazsınız. Ben bu konuda bir kez sıkıntı yaşadım, onda da bir modelimizin tamamen revize etmiştik, bu durumda tek yaptığımız ilgili tabloyu drop edip uygulamayı tekrar çalıştırdık, otomatik olarak tablo oluştu. (jpa.ddl mode)

Ama sanırım, sizin düşüncenize uyan en iyi ORM-DB yönetimlerinden birisi ve Play Framework 2.x'ta kullanılmaya başlanan "Evolutions". Hibernate kadar otomatik değil ama daha kontrollü.

http://www.playframework.com/documentation/2.1.0/Evolutions

(06 Mar '13, 02:23) dreampowder dreampowder's gravatar image

Eski programı tekrar yazıyoruz ve eskisinde sadece jdbc vardı.Aslında benim düşünceme uyan JPA Hibernate implementasyonu diyebiliriz. Bu durumda artıları ve eksilerinin net bir şekilde sunabilmeliyim ki özcan hocanın dedigi gibi confort zone'dan çıkmak istemiyenlere sunabileyim. Umarım ifade edebilmişimdir Yardımlarınız için teşekkürler

(06 Mar '13, 03:33) Alp Alp's gravatar image
Cevabınız
toggle preview

powered by BitNami OSQA