Java Programlama - SQL ifadeleri nerede saklanmalıdır? [kapalı]

JDBC uyumlu bir uygulama SQL ifadelerini nerede depolamalı ve neden?

Şimdiye kadar şu seçenekleri belirlemeyi başardım:

• İş nesnelerinde kodlanmış
• SQLJ cümlelerine gömülü
• Veri Erişim Nesneleri gibi ayrı sınıflarda kapsülleyin
• Meta veriye dayalı (nesne şemasını veri şemasından ayırın - aralarındaki eşlemeleri meta verilerde açıklayın)
• Harici dosyalar (ör. Özellikler veya Kaynak dosyaları)
• Saklanan Prosedürler

Her birinin "Artıları" ve "Eksileri" nelerdir?

SQL kodu “kod” mu yoksa “meta veri” olarak mı düşünülmelidir?

Depolanan prosedürler yalnızca performans optimizasyonu için mi kullanılmalı yoksa veritabanı yapısının meşru bir soyutlaması mıdır?

Performans, kararın ana etkenlerinden biri mi? Satıcıya kilitlenme ne olacak ?

Hangisi daha iyi - gevşek kaplin veya sıkı kaplin ve neden?

DÜZENLENMİŞ: Cevaplar için herkese teşekkür ederim - işte özet:

Meta veriye dayalı yani Nesne İlişkisel Eşleştirmeler (ORM)

Artıları:

• Çok soyut - DB sunucusu, modeli değiştirmeye gerek kalmadan değiştirilebilir
• Geniş yayılı - pratik olarak bir standart
• Gerekli SQL miktarını azaltır
• SQL'i kaynak dosyalarında depolayabilir
• Performans (genellikle) kabul edilebilir
• Meta veriye dayalı yaklaşım
• (Veritabanı) satıcı bağımsızlığı

Eksileri:

• SQL'i ve gerçek geliştiricilerin niyetlerini gizler
• DBA tarafından gözden geçirilmesi / değiştirilmesi zor SQL
• Garip durumlar için SQL hala gerekli olabilir
• Tescilli bir sorgu dilinin (örneğin HQL) kullanılmasını zorlayabilir
• Kendini optimizasyona (soyutlamaya) borç vermez
• Referans bütünlüğünden yoksun olabilir
• SQL bilgisi eksikliğinin veya DB'de kodlama eksikliğinin yerine geçer
• Asla yerel veritabanı performansıyla eşleşmeyin (yaklaşsa bile)
• Model kodu, veritabanı modeliyle çok sıkı bir şekilde birleştirilmiştir

DAO katmanında kodlanmış / kapsüllenmiş

Artıları:

• SQL, verilere erişen nesnelerde tutulur (kapsülleme)
• SQL yazmak kolaydır (geliştirme hızı)
• Değişiklik gerektiğinde SQL'in izini sürmek kolaydır
• Basit çözüm (dağınık mimari yok)

Eksileri:

• SQL, DBA tarafından incelenemez / değiştirilemez
• SQL'in DB'ye özgü olması muhtemeldir
• SQL'in bakımı zorlaşabilir

Saklanan Prosedürler

Artıları:

• Veritabanında tutulan SQL (veriye yakın)
• SQL, DBMS tarafından ayrıştırılır, derlenir ve optimize edilir
• DBA'nın gözden geçirmesi / değiştirmesi için SQL kolaydır
• Ağ trafiğini azaltır
• Yükseltilmiş güvenlik

Eksileri:

• SQL veritabanına bağlıdır (satıcıya kilitlenme)
• SQL kodunun bakımı daha zordur

Harici dosyalar (ör. Özellikler veya Kaynak dosyaları)

Artıları

• Uygulamayı yeniden oluşturmaya gerek kalmadan SQL değiştirilebilir
• SQL mantığını uygulama iş mantığından ayırır
• Tüm SQL ifadelerinin merkezi deposu - bakımı daha kolay
• Anlaşılması daha kolay

Eksileri:

• SQL kodu bakımı yapılamaz hale gelebilir
• SQL kodunu (sözdizimi) hataları için kontrol etmek daha zor

SQLJ cümlelerine gömülü

Artıları:

• Daha iyi sözdizimi denetimi

Eksileri:

• Java ile çok yakın bağlar
• JDBC'den daha düşük performans
• Dinamik sorgu eksikliği
• Çok popüler değil

Genellikle, uygulama boyut ve / veya yeniden kullanılabilirlik açısından ne kadar büyürse, SQL ifadelerini dışsallaştırma / soyutlama ihtiyacı o kadar artar.

Kodlanmış (statik son sabitler olarak) ilk adımdır. Bir dosyada (özellikler / xml dosyası) saklanan sonraki adımdır. Sürülen meta veri (Hibernate / JPA gibi bir ORM tarafından yapıldığı gibi) son adımdır.

Sabit kodlama, kodunuzun DB'ye özgü olma ve her değişiklikte yeniden yazmanız / yeniden oluşturmanız / yeniden dağıtmanız gerekmesi gibi bir dezavantaja sahiptir. Avantajı, onu 1 yerde bulundurmanızdır.

Bir dosyada depolamanın dezavantajı, uygulama büyüdüğünde sürdürülemez hale gelebilir. Avantajı, fazladan bir DAO yöntemi eklemeniz gerekmedikçe uygulamayı yeniden yazmanıza / yeniden oluşturmanıza gerek olmamasıdır.

Sürülen meta veri, model kodunuzun veritabanı modeliyle çok sıkı bir şekilde bağlantılı olması dezavantajına sahiptir. Veritabanı modelindeki her değişiklik için kodu yeniden yazmanız / yeniden oluşturmanız / yeniden dağıtmanız gerekir. Avantajı, çok soyut olması ve modelinizi değiştirmeye gerek kalmadan DB sunucusundan kolayca geçiş yapabilmenizdir (ama şimdi kendinize sorun: bir şirket DB sunucusundan ne sıklıkla geçiş yapar? Muhtemelen en az 3 yılda bir, değil '' t it?).

Depolanmış prosedürlere bunun için "iyi" bir çözüm demeyeceğim. Tamamen farklı bir amaçları var. Yine de, kodunuz kullanılan DB / konfigürasyona bağlı olacaktır.

Bunun en uygun olup olmadığını bilmiyorum, ancak deneyimlerime göre DAO katmanında kodlanmış (yani String değişmezleri) sonuçlanıyorlar.

Oldukça büyük bir soru olduğu için kimsenin size istediğiniz pro / con analizini vereceğini sanmıyorum. Yani bunun yerine geçmişte kullandım ve ileriye dönük olarak kullanacağım şey burada.

DAL'de kodlanmış SQL kullanmak için kullanıyorum. DBA'lar SQL ile oynamak isteyene kadar bunun iyi olduğunu düşündüm. Sonra onu kazmanız, biçimlendirmeniz ve DBA'lara göndermeniz gerekir. Kim ona gülecek ve hepsini değiştirecek. Ama güzel soru işaretleri veya yanlış sırada soru işaretleri olmadan ve onu Java koduna geri yapıştırmanıza izin verir.

Ayrıca bir ORM kullandık ve bu geliştiriciler için harika olsa da DBA'larımız, gülmeleri gereken SQL olmadığı için bundan nefret ediyorlardı. Ayrıca, veritabanını öldürme alışkanlığı olan garip bir ORM (3. taraf tedarikçiden özel bir ORM) kullandık. O zamandan beri JPA kullandım ve harikaydı, ancak DBA'ları geçerek onu kullanarak karmaşık bir şey elde etmek bir tepe savaşı.

Artık Stored Procedures kullanıyoruz (çağrı ifadesi kodlanmış olarak). Şimdi herkesin şikayet edeceği ilk şey, veritabanına bağlı olmanızdır. Sen. Ancak veritabanını ne sıklıkla değiştirdiniz? Bunu yapamayacağımızı bile biliyorum, buna bağlı diğer kodların miktarı artı DBA'larımızı yeniden eğitmek ve verileri taşımak. Çok pahalı bir operasyon olur. Bununla birlikte, dünyanızda bir damla damla DB'leri değiştirmek gerekiyorsa, SP'ler muhtemelen tükenmiştir.

İleriye dönük olarak, Oracle paketlerinden Java sınıfları oluşturmak için kod oluşturma araçlarıyla birlikte saklı yordamları kullanmak istiyorum.

Düzenleme 2013-01-31 : Birkaç yıl ve DBA'lar sonra ve şimdi Hibernate'i kullanıyoruz, yalnızca kesinlikle gerekli olduğunda SQL'e ( DB'de depolanan işlemler) gidiyoruz. Bu bence en iyi çözüm. Veritabanlarının% 99'u SQL hakkında endişelenmelerine gerek kalmaz ve bunu yapanların% 1'i zaten rahat oldukları bir yerde olur.

Bir ORM (örneğin hazırda gibi) kullanarak, umarım olacak hiçbir endişesi ile SQL ifadelerini. Performans genellikle kabul edilebilirdir ve aynı zamanda satıcı bağımsızlığını da elde edersiniz.

SQL kodu “kod” mu yoksa “meta veri” olarak mı düşünülmelidir?

Kod.

Depolanan prosedürler yalnızca performans optimizasyonu için mi kullanılmalı yoksa veritabanı yapısının meşru bir soyutlaması mıdır?

Saklanan prosedürler, diğer saklanan prosedürlerin içi de dahil olmak üzere yeniden kullanıma izin verir. Bu, veritabanına bir gezi yapabileceğiniz ve destekleyici talimatları yürütmesini sağlayabileceğiniz anlamına gelir - en az trafik miktarı idealdir. ORM veya sproc, db'ye ve geri giden kablodaki zaman telafi edemeyeceğiniz bir şeydir.

ORM, soyutlaması nedeniyle optimizasyona borç vermez. IME, ORM aynı zamanda referans bütünlüğünün olmaması anlamına gelir - bir veritabanından raporlamayı zorlaştırın. Karmaşıklıktan kurtarılan şey, verileri uygulanabilir bir şekilde dışarı çıkarabilmek için arttı.

Performans, kararın ana etkenlerinden biri mi? Satıcıya kilitlenme ne olacak?

Hayır, basitlik öyle. Satıcı kilitlenmesi veritabanında da gerçekleşir - SQL nispeten standartlaştırılmıştır, ancak yine de satıcıya özgü bir şeyler yapmanın yolları vardır.

Java dünyasında satıcı kilitlenmesi korkusu ilginç.

Umarım Oracle Enterprise için 50000 $ pr CPU ödememişsinizdir ve daha sonra herhangi bir dakika Mysql'e geçmek için yalnızca en az ortak paydayı kullandınız. Herhangi bir iyi DBA'nın size söyleyeceği gibi, farklı büyük isim veritabanları arasında, özellikle kilit modelleri ve tutarlılığı nasıl sağladıklarına ilişkin ince farklar vardır.

Bu nedenle, SQL çağrılarınızı yalnızca satıcı bağımsız SQL ilkesine dayalı olarak nasıl uygulayacağınıza karar vermeyin - bunu yapmak için gerçek bir (iş) nedeniniz olsun.

Depolanan Prosedürler içindeki SQL, veritabanı sistemi tarafından optimize edilir ve hız için derlenir - bu onun doğal yuvasıdır. SQL, veritabanı sistemi tarafından çözümlenen veritabanı sistemi tarafından anlaşılır. Mümkünse SQL'inizi veritabanında tutun; bunu saklı yordamlara veya işlevlere veya veritabanı sisteminin sağladığı mantık birimlerine sarın ve sizin veya başka birinin bahsettiği araçlardan herhangi birini kullanarak basit aramalar yapın.

Veritabanı sistemi için SQL kodunu neden veritabanının dışında depolamalıyım? Genellikle geliştirme hızı için. ORM eşleştirmesini neden kullanmalısınız? - Bazıları ORM eşlemesinin farklı veritabanı sistemleri arasında uyumluluk sağladığını söylüyor; ancak gerçek dünyada nadiren bir uygulama veritabanı platformundan uzaklaşır ve özellikle replikasyon gibi gelişmiş özellikleri kullanmaya başladığında oluşturulur ve nadiren de olsa veritabanı sistemi değiştirilir, bazı çalışmalar garanti edilir. . ORM'nin dezavantajlarından birinin, genellikle SQL bilgisi eksikliğinin veya veritabanında kodlama konusundaki özen eksikliğinin yerini aldığına inanıyorum. Ayrıca ORM, yaklaşsa bile yerel veritabanı performansıyla asla eşleşmeyecektir.

SQL kodunu veritabanında tutmanın yanında duruyorum ve kullanmak istediğiniz herhangi bir API veya arayüz aracılığıyla ona basit çağrılar yapıyorum. Ayrıca, bu çağrıları soyut bir sınıfın veya OO arayüzünün (yöntemlerle ifade edilir) arkasına koyarak veritabanı çağrılarınızın yapıldığı noktayı soyutlayın, böylece yeni bir tür veri kaynağında takas yaparsanız, iş katmanında sorunsuz olacaktır. .

Kesin bir cevabı olan sorduğunuz tek soru "SQL kodu mu yoksa meta veri mi?" Bu kesinlikle kodudur ve gibi kaynak kod denetimi çeşit tutulur ve kolayca son sürüme güncellenmesi ve arka haddeleme için bir sisteme sahip olmalıdır zaman terslik değilse.

Bir uygulamada SQL yapmanın üç yolunu gördüm ve her birinin artıları ve eksileri var. En iyi yol yoktur, ancak en iyi şey, uygulamanıza uygun olanı seçip ona bağlı kalmaktır.

• ORM - bu, yazmanız gereken SQL miktarını azaltır ve sizin için birçok ayrıntıyı işler. Bazı özel SQL yapmanız gerekecek. Bunu düzgün bir şekilde ele alan bir ORM'ye sahip olduğunuzdan emin olun.
• Veri Erişim Nesneleri - SQL'i verilere erişen nesnelerde tutun. Bu, veritabanınızı kapsüller ve uygulamanızın geri kalanının temeldeki DB yapısı hakkında bilgi sahibi olmasına gerek kalmaması, yalnızca bu nesnelerin arayüzü hakkında bilgi sahibi olmasını sağlar.
• Depolanan Prosedürler - bu, tüm SQL'inizi veritabanınızda tutar ve DBA'larınızın neler olup bittiğini bilmesini kolaylaştırır. Tek yapmanız gereken kodunuzun kayıtlı işlemleri çağırmasını sağlamaktır.

Hibernate gibi ORM'lerden daha metale daha yakın olan iBatis SQL eşleştiricisini kullanıyoruz. İBatis'te SQL deyimlerini, sınıf yolunda olması gereken kaynak dosyalarına (XML) koyarsınız.

@ Ocdecio'nun ORM seçeneğini eklerseniz, yaklaşım listeniz oldukça kapsamlı görünür. Bir ORM kullanmanın ve bir SQL eşleştiricisi ve kaynak dosyaları kullanmanın en iyi iki yaklaşım olduğunu söyleyebilirim. Çok fazla ilgi görmeyen ve sizi Java ile çok yakından bağlayan SQLJ'den uzak dururum. Ayrıca, sizi belirli bir veritabanı satıcısına bağladıkları için saklı yordamlardan uzak durun (depolanmış yordamlar için standartlar neredeyse yoktur).

Çoğumuz gibi ben de tüm gamı ​​gördüm ama SQL'i birinci sınıf bir dil olarak kabul etmemiz gerekiyor. DB'de depolanan ve aşağı çekilip yeniden çalıştırılan SQL'i bile gördüm.

Gördüğüm en başarılı sistemler saklı yordamları, işlevleri ve görünümleri kullanır.

Depolanan işlemler, SQL metnini DB'de tutar ve KURULUM VE ÖZELLEŞTİRME (bunu desteklemek için çok sayıda uygun tasarım gerektirir) tarafından nispeten anında değişikliğe izin verir.

Tüm projeksiyonlar, aynı nedenlerle görünümler ve basit seçimler yoluyla olmalıdır, tüm projeksiyon mantığı görünümün içinde yer almalıdır.

DAO'ları fabrika düzeniyle kullanmanızı öneririm. Dolayısıyla, ihtiyacınız olan örnek nesneler şunlar olacaktır:

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

Bu stil veri etkileşimini katmanlandırır, bu nedenle veritabanlarını değiştirirseniz veya ORM teknolojilerine geçerseniz yalnızca bir kod katmanını değiştirmeniz gerekir.

Bu üçü arasında gerçekten önemli bir fark yok:

1. İş nesnelerinde kodlanmış
2. SQLJ cümlelerine gömülü
3. Veri Erişim Nesneleri gibi ayrı sınıflarda kapsülleyin

SQL kodunu bir dize biçiminde doğrudan Java kodunuzun içine yerleştireceğinizi varsayıyorum. 1 ve 3 muhtemelen doğrudan JDBC'yi (veya Apache DbUtils gibi bazı araçları ) kullanacak olsa da , 2 yığına bir ön işlemci teknolojisi ekleyerek derlemeden önce ilgili JDBC kodunu üretir .

Dolayısıyla, esasen, eğer bu çözümler SQL yerleştirmeyi içeriyorsa, şu teknolojilerden herhangi birini de kullanabilirsiniz:

• JPA Criteria API , JPQL'i Java'da etki alanına özel dahili bir dil olarak modelliyor
• jOOQ , SQL'i Java'da dahili bir etki alanına özgü dil olarak modelliyor

Ayrıca, SQL'i Java'ya SQLJ'den veya gerçek dize birleştirme yoluyla olduğundan daha tür güvenli bir şekilde yerleştirmenize yardımcı olacak başka araçlar da olabilir.

Sahip olduğum tecrübelere göre DAO nesnelerinde sql ifadelerini sabit kodlamak yaygın olarak kullanılan yöntem olsa da, en az tercih edilen yöntem olduğunu düşünüyorum. En iyi uygulama, sql ifadelerini bir özellikler dosyasında saklamak olmalıdır. Ve DAO nesnesindeki ifadeleri java.util.Properties gibi özellikler dosyalarına bir arayüz aracılığıyla alın . Hazırlanmış İfade yaklaşımı aracılığıyla parametreleri geçirmek için sql ifadeleri arasına "?"

Böyle bir yaklaşım, sql mantığını uygulama iş mantığından ayırmaya yardımcı olur. Bu, tüm sql ifadelerinin merkezi bir deposunu kullanılabilir hale getirir, bu da değişikliği kolaylaştırır ve uygulama mantığı içinde veritabanı ifadelerini arama ihtiyacını ortadan kaldırır.

Maden kaynak paketlerinde bitiyor. Bunun normal olmadığını biliyorum ama benim ve "benden başka" herkes için bakımı en kolay olanı. Basit ve mantıklı.

Aslında benim yaklaşımımı kullanan biri olup olmadığını merak ediyorum.

Bir rexem'in yazdığı gibi, SQL ifadeleri koddur - bunlar dışsallaştırılmamış (iyi bir nedeniniz olmadığı sürece) kod gibi ele alınmalı, ancak bu ifadelerden / ifadelerden SQL verilerini işleyen kodla yerleştirilmelidir. Günümüz çerçevesi ORM'leri / iBatis, günlük JDBC geliştirme için birçok basitleştirme sunar.

Sorunuza Bazı cevaplar bulacaksınız bu soruya :) senin SQL statments saklanacağı nasıl Sorun uygulamanızda kralı bağlıdır. İhtiyaçlarınız neler? Yüksek güvenlik, kod yazma veya bakım kolaylığı, platformlar arası veya satıcıya bağlılık? Sıradaki soru saf SQL'e ihtiyacınız var mı yoksa ORM çerçevesi iyi olacak mı?

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

En basit çözüm (P), bakımı zor (C)

* Embedded in SQLJ clauses

Daha iyi sözdizimi denetimi (P), dinamik sorgulardan yoksun (C), JDBC'den (C) daha düşük performans, çok popüler değil (C)

* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)

Bunu yapmanız gereken özel bir durum olmalıdır (C) veya ORM (P) demek istiyorsanız;)

* External files (e.g. Properties or Resource files)

Bakımı kolay (P) ancak hataları kontrol etmesi daha zor (C)

* Stored Procedures

Yüksek güvenlik (P), bir satıcıya kilitlenme problemlerini çözmek zor olan kod (C)