Pemrograman Java - Di mana pernyataan SQL harus disimpan? [Tutup]

Di mana aplikasi yang sesuai dengan JDBC harus menyimpan pernyataan SQL-nya dan mengapa?

Sejauh ini, saya berhasil mengidentifikasi opsi-opsi ini:

• Hardcode di objek bisnis
• Disematkan dalam klausa SQLJ
• Mengenkapsulasi dalam kelas terpisah misalnya Objek Akses Data
• Didorong metadata (pisahkan skema objek dari skema data - jelaskan pemetaan di antara keduanya dalam metadata)
• File eksternal (misalnya Properti atau file Sumber Daya)
• Prosedur Tersimpan

Apa “Pro” dan “Kontra” untuk masing-masing?

Haruskah kode SQL dianggap sebagai "kode" atau "metadata"?

Haruskah prosedur tersimpan digunakan hanya untuk pengoptimalan kinerja atau merupakan abstraksi sah dari struktur database?

Apakah kinerja merupakan faktor kunci keputusan? Bagaimana dengan vendor lock-in ?

Apa yang lebih baik - kopling longgar atau kopling ketat dan mengapa?

DIEDIT: Terima kasih semuanya atas jawabannya - berikut ringkasannya:

Metadata didorong yaitu Object Relational Mappings (ORM)

Kelebihan:

• Sangat abstrak - Server DB dapat diaktifkan tanpa perlu mengubah model
• Tersebar luas - praktis standar
• Mengurangi jumlah SQL yang dibutuhkan
• Dapat menyimpan SQL dalam file sumber daya
• Performa (biasanya) dapat diterima
• Pendekatan berbasis metadata
• (Database) independensi vendor

Kekurangan:

• Menyembunyikan SQL dan niat developer sejati
• SQL sulit untuk direview / diubah oleh DBA
• SQL mungkin masih diperlukan untuk kasus ganjil
• Dapat memaksa penggunaan bahasa query berpemilik misalnya HQL
• Tidak cocok untuk pengoptimalan (abstraksi)
• Bisa kekurangan integritas referensial
• Pengganti karena kurangnya pengetahuan SQL atau kurangnya perawatan untuk kode di DB
• Jangan pernah cocok dengan kinerja database asli (bahkan jika mendekati)
• Kode model sangat erat digabungkan dengan model database

Hardcode / dienkapsulasi dalam lapisan DAO

Kelebihan:

• SQL disimpan dalam objek yang mengakses data (enkapsulasi)
• SQL mudah untuk ditulis (kecepatan pengembangan)
• SQL mudah dilacak saat ada perubahan
• Solusi sederhana (tidak ada arsitektur yang berantakan)

Kekurangan:

• SQL tidak dapat ditinjau / diubah oleh DBA
• SQL cenderung menjadi khusus DB
• SQL bisa menjadi sulit untuk dipertahankan

Prosedur Tersimpan

Kelebihan:

• SQL disimpan dalam database (dekat dengan data)
• SQL diurai, dikompilasi, dan dioptimalkan oleh DBMS
• SQL mudah ditinjau / diubah oleh DBA
• Mengurangi lalu lintas jaringan
• Peningkatan keamanan

Kekurangan:

• SQL terikat ke database (vendor lock-in)
• Kode SQL lebih sulit untuk dipertahankan

File eksternal (misalnya Properti atau file Sumber Daya)

Pro

• SQL dapat diubah tanpa perlu membangun kembali aplikasi
• Memisahkan logika SQL dari logika bisnis aplikasi
• Repositori pusat dari semua pernyataan SQL - lebih mudah dikelola
• Lebih mudah dimengerti

Kekurangan:

• Kode SQL bisa menjadi tidak bisa dipelihara
• Lebih sulit untuk memeriksa kode SQL untuk kesalahan (sintaks)

Disematkan dalam klausa SQLJ

Kelebihan:

• Pemeriksaan sintaks yang lebih baik

Kekurangan:

• Hubungannya terlalu dekat dengan Jawa
• Performa lebih rendah dari JDBC
• Kurangnya kueri dinamis
• Tidak begitu populer

Biasanya, semakin aplikasi tumbuh dalam hal ukuran dan / atau usabilitas, semakin banyak kebutuhan untuk mengeksternalisasi / mengabstraksi pernyataan SQL.

Hardcode (sebagai konstanta akhir statis) adalah langkah pertama. Disimpan dalam file (file properti / xml) adalah langkah berikutnya. Metadata driven (seperti yang dilakukan oleh ORM seperti Hibernate / JPA) adalah langkah terakhir.

Kekurangan hardcode memiliki kelemahan bahwa kode Anda cenderung menjadi khusus DB dan Anda perlu menulis ulang / membangun kembali / mendistribusikan ulang pada setiap perubahan. Keuntungannya adalah Anda memilikinya di 1 tempat.

Disimpan dalam file memiliki kelemahan yaitu dapat menjadi tidak dapat dipertahankan saat aplikasi berkembang. Keuntungannya adalah Anda tidak perlu menulis ulang / membangun kembali aplikasi, kecuali Anda perlu menambahkan metode DAO tambahan.

Metadata didorong memiliki kelemahan yaitu kode model Anda sangat erat digabungkan dengan model database. Untuk setiap perubahan dalam model database, Anda harus menulis ulang / membangun kembali / mendistribusikan ulang kode. Keuntungannya adalah sangat abstrak dan Anda dapat dengan mudah beralih dari server DB tanpa perlu mengubah model Anda (tetapi tanyakan pada diri Anda sekarang: seberapa sering sebuah perusahaan beralih dari server DB? Mungkin setidaknya hanya sekali per 3 tahun, bukan? t itu?).

Saya tidak akan menyebut prosedur tersimpan sebagai solusi yang "baik" untuk ini. Mereka memiliki tujuan yang sama sekali berbeda. Meskipun demikian, kode Anda akan bergantung pada DB / konfigurasi yang digunakan.

Saya tidak tahu apakah ini optimal, tetapi dalam pengalaman saya, mereka berakhir dengan hardcode (yaitu string literal) di lapisan DAO.

Saya tidak berpikir ada orang yang akan memberi Anda pro / kontra yang Anda inginkan karena ini adalah pertanyaan yang agak besar. Jadi, inilah yang saya gunakan di masa lalu, dan apa yang akan saya gunakan di masa mendatang.

Saya menggunakan SQL hardcode di DAL. Saya pikir ini baik-baik saja sampai DBA ingin bermain dengan SQL. Kemudian Anda harus menggalinya, memformatnya, dan menjalankannya ke DBA. Siapa yang akan menertawakannya dan mengganti semuanya. Tapi tanpa tanda tanya yang bagus, atau tanda tanya dalam urutan yang salah dan membiarkan Anda menempelkannya kembali ke kode Java.

Kami juga telah menggunakan ORM, dan meskipun ini bagus untuk pengembang, DBA kami membencinya karena tidak ada SQL yang dapat mereka tawa. Kami juga menggunakan ORM aneh (ORM khusus dari pemasok pihak ke-3) yang memiliki kebiasaan mematikan database. Saya telah menggunakan JPA sejak itu dan hebat, tetapi mendapatkan sesuatu yang rumit dengan menggunakannya melewati DBA adalah perjuangan yang sulit.

Kami sekarang menggunakan Prosedur Tersimpan (dengan pernyataan panggilan hardcode). Sekarang hal pertama yang akan dikeluhkan semua orang adalah bahwa Anda terikat dengan database. Kamu adalah. Namun seberapa sering Anda mengubah database? Saya tahu pasti bahwa kami bahkan tidak dapat mencobanya, jumlah kode lain yang bergantung padanya ditambah pelatihan ulang DBA kami serta memigrasi data. Ini akan menjadi operasi yang sangat mahal. Namun jika di dunia Anda mengubah DB dengan mudah diperlukan SP kemungkinan besar keluar.

Untuk selanjutnya saya ingin menggunakan prosedur tersimpan dengan alat pembuat kode untuk membuat kelas Java dari paket Oracle.

Sunting 2013-01-31 : Beberapa tahun dan DBA kemudian dan sekarang kita menggunakan Hibernate, pergi ke SQL (procs tersimpan di DB) hanya jika benar-benar diperlukan. Ini menurut saya adalah solusi terbaik. 99% dari waktu DB tidak perlu khawatir tentang SQL, dan 1% yang mereka lakukan berada di tempat yang sudah mereka sukai.

Dengan menggunakan ORM (seperti hibernate), Anda diharapkan tidak memiliki pernyataan SQL yang perlu dikhawatirkan. Performa biasanya dapat diterima dan Anda juga mendapatkan kebebasan vendor.

Haruskah kode SQL dianggap sebagai "kode" atau "metadata"?

Kode.

Haruskah prosedur tersimpan digunakan hanya untuk pengoptimalan kinerja atau merupakan abstraksi sah dari struktur database?

Prosedur tersimpan memungkinkan untuk digunakan kembali, termasuk di dalam prosedur tersimpan lainnya. Ini berarti Anda dapat melakukan satu perjalanan ke database & membuatnya menjalankan instruksi pendukung - jumlah lalu lintas paling sedikit adalah ideal. ORM atau sproc, waktu di kabel menuju ke db & kembali adalah sesuatu yang tidak dapat Anda ganti.

ORM tidak cocok untuk pengoptimalan karena abstraksinya. IME, ORM juga berarti kurangnya integritas referensi - membuat database sulit untuk dilaporkan. Apa yang disimpan dalam kompleksitas, kini telah meningkat untuk dapat mengeluarkan data dengan cara yang bisa diterapkan.

Apakah kinerja merupakan faktor kunci keputusan? Bagaimana dengan vendor lock-in?

Tidak, kesederhanaan. Lokasi vendor juga terjadi dengan database - SQL relatif terstandarisasi, tetapi masih ada cara khusus vendor untuk melakukan sesuatu.

Ketakutan akan vendor lock-in di dunia java memang menarik.

Saya harap Anda belum membayar CPU $ 50.000 untuk Oracle Enterprise, dan kemudian hanya menggunakan penyebut yang paling tidak umum untuk beralih ke Mysql setiap saat. Seperti DBA yang baik akan memberitahu Anda, ada perbedaan halus antara database nama besar yang berbeda, terutama yang berkaitan dengan model penguncian dan bagaimana mereka mencapai konsistensi.

Jadi, jangan membuat keputusan tentang cara mengimplementasikan panggilan SQL Anda hanya berdasarkan prinsip vendor agnostik SQL - miliki alasan (bisnis) yang nyata untuk melakukannya.

SQL di dalam Prosedur Tersimpan dioptimalkan oleh sistem database dan dikompilasi untuk kecepatan - itulah rumah aslinya. SQL dipahami oleh sistem database, diurai oleh sistem database. Simpan SQL Anda di database jika Anda bisa; membungkusnya dalam prosedur atau fungsi yang tersimpan atau unit logika apa pun yang disediakan oleh sistem database, dan membuat panggilan sederhana ke sana menggunakan salah satu alat yang Anda atau orang lain sebutkan.

Mengapa menyimpan kode SQL untuk sistem database di luar db? Seringkali untuk kecepatan perkembangan. Mengapa menggunakan pemetaan ORM? - Beberapa orang mengatakan pemetaan ORM menyediakan kompatibilitas di seluruh sistem database yang berbeda; Namun jarang di dunia nyata sebuah aplikasi pernah bergeser dari platform basis data setelah dibangun terutama ketika ia mulai menggunakan fitur-fitur canggih seperti replikasi, dan untuk kejadian yang jarang terjadi bahwa sistem basis data ditukar, beberapa pekerjaan dijamin . Saya percaya salah satu kelemahan ORM itu sering menggantikan kurangnya pengetahuan SQL atau kurangnya perawatan untuk kode di db. Juga ORM tidak akan pernah cocok dengan kinerja database asli bahkan jika mendekati.

Saya berdiri di sisi menyimpan kode SQL dalam database dan membuat panggilan sederhana melalui API atau antarmuka yang ingin Anda gunakan. Juga abstraksi titik di mana panggilan database Anda dibuat dengan meletakkan panggilan tersebut di belakang kelas abstrak atau antarmuka OO (diekspresikan oleh metode), jadi jika Anda pernah melakukan pertukaran dalam jenis sumber data baru, itu akan mulus ke lapisan bisnis .

Satu-satunya pertanyaan yang Anda ajukan yang memiliki jawaban pasti adalah "Apakah kode SQL atau metadata?" Ini adalah kode yang paling pasti dan karena itu harus disimpan dalam semacam kontrol kode sumber dan memiliki sistem untuk dengan mudah memperbarui ke versi terbaru dan memutar kembali jika tidak ada yang salah.

Saya telah melihat tiga cara melakukan SQL dalam sebuah aplikasi dan masing-masing memiliki pro & kontra. Tidak ada cara terbaik, tetapi yang terbaik adalah memilih salah satu yang bekerja dengan baik dengan aplikasi Anda dan tetap menggunakannya.

• ORM - ini mengurangi jumlah SQL yang Anda butuhkan untuk menulis dan menangani banyak detail untuk Anda. Anda perlu melakukan beberapa SQL kustom. Pastikan Anda memiliki ORM yang menangani ini dengan baik.
• Objek Akses Data - pertahankan SQL di objek yang mengakses data. Ini merangkum database Anda dan membuatnya sehingga aplikasi Anda lainnya tidak perlu tahu tentang struktur DB yang mendasarinya, hanya antarmuka ke objek ini.
• Prosedur Tersimpan - ini menyimpan semua SQL Anda di database dan memudahkan DBA Anda mengetahui apa yang sedang terjadi. Yang perlu Anda lakukan adalah meminta kode Anda memanggil procs yang tersimpan

Kami kebetulan menggunakan mapper iBatis SQL, yang lebih dekat ke logam daripada ORM seperti Hibernate. Di iBatis Anda meletakkan pernyataan SQL ke dalam file sumber daya (XML), yang harus berada di jalur kelas.

Daftar pendekatan Anda tampaknya cukup lengkap jika Anda menambahkan opsi ORM @ ocdecio. Saya akan mengatakan bahwa menggunakan ORM dan menggunakan pemeta SQL dan file sumber daya adalah dua pendekatan terbaik. Saya akan menghindari SQLJ, yang belum melihat banyak penyerapan dan mengikat Anda terlalu dekat dengan Java. Juga menjauh dari prosedur tersimpan, karena mereka mengikat Anda ke vendor database tertentu (standar hampir tidak ada untuk prosedur tersimpan).

Seperti kebanyakan dari kita, saya telah melihat keseluruhan gammut tetapi kita perlu mempertimbangkan SQL sebagai bahasa kelas satu. Saya bahkan pernah melihat SQL yang disimpan di DB yang ditarik ke bawah lalu dieksekusi kembali.

Sistem paling sukses yang pernah saya lihat menggunakan prosedur, fungsi, dan tampilan yang tersimpan.

Procs yang disimpan menyimpan teks SQL kembali di DB dan memungkinkan perubahan yang relatif segera oleh mereka yang MENYESUAIKAN dan MENYESUAIKAN (yang membutuhkan banyak desain yang tepat untuk mendukungnya).

Semua proyeksi harus melalui tampilan dan pemilihan sederhana karena alasan yang sama, semua logika proyeksi harus terkandung dalam tampilan.

Saya menyarankan menggunakan DAO dengan tata letak pabrik. Jadi contoh objek yang Anda butuhkan adalah:

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

Gaya ini melapisi interaksi data, jadi Anda hanya perlu mengubah satu lapisan kode jika Anda beralih database, atau pindah ke teknologi ORM.

Sebenarnya tidak ada perbedaan substansial antara ketiganya:

1. Hardcode di objek bisnis
2. Tersemat di SQLJklausa
3. Mengenkapsulasi dalam kelas terpisah misalnya Objek Akses Data

Saya berasumsi bahwa Anda akan menyematkan kode SQL dalam bentuk string langsung ke kode Java Anda. Sementara 1 dan 3 mungkin akan menggunakan JDBC secara langsung (atau beberapa alat seperti Apache DbUtils ), 2 menambahkan teknologi preprocessor ke stack, menghasilkan kode JDBC yang relevan sebelum kompilasi.

Jadi, pada dasarnya, jika solusi ini melibatkan penyematan SQL, Anda mungkin juga menggunakan salah satu teknologi berikut:

• API Kriteria JPA , memodelkan JPQL sebagai bahasa khusus domain internal di Java
• jOOQ , memodelkan SQL sebagai bahasa khusus domain internal di Java

Mungkin juga ada alat lain untuk membantu Anda menyematkan SQL di Java dengan cara yang lebih aman untuk mengetik daripada melalui SQLJ atau melalui penggabungan string yang sebenarnya.

Dari pengalaman apa yang saya miliki, pernyataan hard coding sql di objek DAO adalah apa yang banyak digunakan, meskipun, saya pikir itu harus menjadi metode yang paling tidak disukai. Praktik terbaiknya adalah menyimpan pernyataan sql dalam file properti. Dan dapatkan pernyataan di objek DAO melalui antarmuka ke file properti, misalnya java.util.Properties . Pernyataan sql dapat diselingi dengan '?' Untuk melewatkan parameter, melalui Pernyataan Disiapkan pendekatan .

Pendekatan seperti itu membantu memisahkan logika sql dari logika bisnis aplikasi. Ini menyediakan repositori pusat dari semua pernyataan sql, yang membuat modifikasi lebih mudah, menghilangkan kebutuhan untuk mencari pernyataan database dalam logika aplikasi.

Punyaku berakhir di bundel sumber daya. Saya tahu itu tidak normal tetapi itu yang paling mudah bagi saya dan siapa pun "selain saya" untuk mempertahankannya. Ini mudah dan logis.

Saya sebenarnya penasaran untuk melihat apakah ada yang menggunakan pendekatan saya juga.

Sebagai rexem menulis pernyataan SQL adalah kode - mereka harus diperlakukan seperti kode, tidak dieksternalisasi (kecuali Anda memiliki alasan yang baik) tetapi ditempatkan dengan kode yang memproses data SQL dari / ke pernyataan itu. Framework hari ini ORMs / iBatis menawarkan banyak penyederhanaan untuk pengembangan JDBC sehari-hari.

Beberapa jawaban atas pertanyaan Anda akan Anda temukan di pertanyaan ini :) Masalah bagaimana statments SQL Anda akan disimpan tergantung dari raja aplikasi Anda. Apa kebutuhan anda Keamanan tinggi, kemudahan penulisan kode atau pemeliharaan, crossplatform atau vendor lock-in? Pertanyaan berikutnya apakah Anda membutuhkan SQL murni atau kerangka ORM akan baik?

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

Solusi paling sederhana (P), sulit dirawat (C)

* Embedded in SQLJ clauses

Pemeriksaan sintaks yang lebih baik (P), kurangnya kueri dinamis (C), kinerja yang lebih rendah daripada JDBC (C), tidak begitu populer (C)

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

Ini harus kasus spesifik Anda harus melakukan itu (C) atau jika yang Anda maksud ORM (P);)

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

Mudah untuk mempertahankan (P) tetapi lebih sulit untuk memeriksa kesalahan (C)

* Stored Procedures

Keamanan tinggi (P), kode sulit untuk menjaga masalah penguncian vendor (C)