CATATAN Audiens programmer.se dan dba.se berbeda, dan akan memiliki sudut pandang yang berbeda, jadi dalam hal ini saya pikir itu sah untuk menduplikasi Apa argumen yang menentang atau untuk menempatkan logika aplikasi di lapisan database? di programmer.se.
Saya sudah tidak dapat menemukan diskusi tentang dba tentang ini, dan posting asli mengatakan itu semua, jadi:
Sebagian besar pengembang perangkat lunak ingin menyimpan logika aplikasi di lapisan aplikasi, dan mungkin terasa alami bagi kita untuk menyimpannya di sini. Pengembang basis data tampaknya ingin memasukkan logika aplikasi ke dalam lapisan basis data, sebagai pemicu dan prosedur tersimpan.
Secara pribadi saya lebih suka menyimpan sebanyak mungkin di lapisan aplikasi untuk membuatnya lebih mudah untuk debug dan menjaga tanggung jawab lapisan terpisah.
Apa pendapat Anda tentang ini, dan apa yang harus atau tidak boleh diterapkan pada lapisan basis data?
NB Saya bukan OP untuk pertanyaan itu, tetapi membiarkan kata-kata aslinya tetap utuh.
sumber
Jawaban:
Berbagai macam pemikiran ...
Kode database Anda akan hidup lebih lama dari teknologi klien aplikasi Anda. Pikirkan ADO.NET -> Linq -> EF serta berbagai macam ORM. Sedangkan Anda masih dapat menjalankan kode SQL Server 2000 dari milenium terakhir terhadap semua teknologi klien di atas.
Anda juga memiliki beberapa masalah klien: Saya punya .net, java dan Excel. Itu 3 set logika aplikasi.
"Logika bisnis" tidak boleh disamakan dengan "logika integritas data". Jika Anda memiliki klien memulai transaksi dan melakukan berbagai macam cek, itu banyak panggilan db dan transaksi panjang.
Logika aplikasi tidak menskala untuk volume data tinggi. Kami memiliki 50rb baris per detik menggunakan procs yang disimpan. Tim saudara yang menggunakan Hibernate tidak bisa mendapatkan satu per detik
sumber
Saya ingin semua logika yang berlaku untuk semua pengguna dan semua aplikasi dalam database. Itu satu-satunya tempat yang waras untuk mengatakannya.
Fortune 500 terakhir yang saya kerjakan memiliki aplikasi yang ditulis dalam setidaknya 25 bahasa yang mencapai basis data OLTP mereka. Beberapa dari program tersebut mulai berproduksi pada tahun 1970-an.
Alternatif untuk menerapkan persyaratan semacam ini dalam database adalah membiarkan setiap pemrogram aplikasi menerapkan kembali semua atau sebagian dari itu 100% dengan benar, setiap kali mereka menjalankan editor mereka, dari hari pertama mereka berjalan melewati pintu sampai perusahaan keluar dari bisnis.
Apa peluangnya?
Bukankah ini satu-satunya yang terbesar " jangan ulangi dirimu " di planet ini?
sumber
Saya memindahkan jawaban lama saya ke yang belum diedit dari programmer.se, karena jawaban tampaknya cukup terpolarisasi di antara beberapa situs.
sumber
Masalah yang paling penting adalah apakah ada 'lapisan' di atas database yang berpikir bahwa ia memiliki data. Konkurensi dan integritas data adalah masalah yang solusinya adalah RDBMS - beberapa aplikasi dikembangkan seolah-olah basis data hanyalah ember bit pribadi mereka dan tentu saja mereka akhirnya mencoba menemukan kembali roda dengan berbagai cara, serta rusak tidak dapat diperbaiki segera setelah beberapa aplikasi lain mengakses database yang sama
sumber
Saya menulis jawaban saya untuk ini di blog saya . Kesimpulan saya adalah, melakukannya dalam aplikasi tidak akan menjadi skala setelah Anda mempertimbangkan seluruh siklus hidup aplikasi.
sumber
Apakah SQL melakukan hal-hal seperti mengatur logika dan penyaringan hasil berorientasi aplikasi? SQL adalah bahasa manipulasi set yang indah.
Selain itu, seperti yang ditunjukkan GBN di atas, kode SQL hampir secara universal akan hidup lebih lama dari kode aplikasi.
Meskipun benar bahwa EF atau NHibernate atau LinqToSql atau apa pun akan memungkinkan Anda untuk menghasilkan kode lebih cepat, setiap programmer yang menghargai kinerjanya tahu bahwa hanya mengoptimalkan SQL yang akan mengoptimalkan pengambilan data. RDBMS hanya memahami SQL, jadi Anda harus membuat semuanya menjadi SQL sebelum semuanya dikatakan dan dilakukan. (dengan asumsi kita dapat menyetujui bahwa TSQL dan PLSQL masih SQL)
sumber
Satu con yang orang tidak perlu mendiskusikan - pro telah habis di sini - adalah biaya.
CPU pada server database sering kali merupakan CPU paling mahal di organisasi mana pun ketika dipanggang dengan biaya lisensi perangkat lunak. Jadi memindahkan logika bisnis ke tingkat data adalah sesuatu yang harus dilakukan dengan bijaksana, tidak harus seragam.
sumber
Di sinilah pertemuan pikiran, yaitu, pikiran Pengembang (DV) dan DBA, pasti terjadi. Bekerja dengan Business Logic (BL) dan menyimpannya dalam database dapat memiliki dampak yang dapat memuliakan atau mengerikan implementasinya.
Untuk beberapa produk RDBMS, terdapat perpustakaan / alat / API unggul untuk Logika Bisnis dan Infrastruktur Objek yang dapat dengan cepat dipelajari dan digunakan dalam aplikasi mereka. Untuk RDBMS lainnya, tidak ada perpustakaan / alat / API.
Di masa lalu, aplikasi server klien membuat jembatan menjadi BL melalui Stored Procedures (SP). Untuk produk-produk seperti Oracle dan SQL Server, ini dilakukan lebih awal. Ketika database open source seperti PostgreSQL dan MySQL muncul, mereka yang menggunakannya berisiko melanggar tanah baru dengan prosedur tersimpan di BL. PostgreSQL matang dengan sangat cepat dalam hal ini, karena tidak hanya prosedur tersimpan yang diterapkan tetapi juga kemampuan untuk membuat bahasa pelanggan juga muncul. MySQL pada dasarnya berhenti berkembang dalam dunia prosedur tersimpan dan datang dalam bentuk bahasa yang dipreteli dengan banyak batasan. Jadi, ketika datang ke BL, Anda sepenuhnya bergantung pada MySQL dan bahasa Stored Procedure-nya.
Hanya ada satu pertanyaan: Terlepas dari RDBMS, haruskah BL berada secara keseluruhan atau sebagian dalam basis data?
Pikirkan Pengembang. Ketika hal-hal serba salah dalam suatu aplikasi, proses debug akan membuat Pengembang masuk dan keluar dari database untuk mengikuti saluran data yang mungkin atau mungkin tidak benar sebentar-sebentar. Ini seperti mengkode aplikasi C ++ dan memanggil kode Assembler di tengah. Anda harus beralih dari kode sumber, kelas, dan struct ke interupsi, register dan offset DAN KEMBALI !!! Ini mengambil debugging ke tingkat yang sama.
Pengembang mungkin dapat membuat metode kecepatan tinggi dalam mengeksekusi BL bersamaan dengan konfigurasi bahasa (flag kompiler untuk C ++, pengaturan berbeda untuk PHP / Python, dll) melalui objek bisnis yang berada di memori daripada di database. Beberapa telah mencoba menjembatani ideologi ini untuk kode runnng yang lebih cepat ke dalam database dengan menulis pustaka di mana debugging Stored Procedures dan Pemicu terintegrasi dengan baik dalam Database dan tampaknya dapat digunakan.
Dengan demikian, Pengembang ditantang untuk mengembangkan, men-debug, dan memelihara kode sumber dan BL dalam dua bahasa.
Sekarang pikirkan DBA. DBA ingin menjaga Basis Data tetap ramping dan berarti sebanyak mungkin dalam bidang prosedur tersimpan. DBA dapat melihat BL sebagai sesuatu yang berada di luar Basis Data. Namun, ketika SQL meminta data yang dibutuhkan untuk BL, SQL harus ramping dan berarti.
Sekarang, untuk pertemuan pikiran !!!
Kode pengembang SP dan menggunakan metode iteraktif. DBA melihat SP. DBA menentukan bahwa pernyataan SQL tunggal dapat menggantikan metode iteraktif yang ditulis oleh Pengembang. Pengembang melihat bahwa pernyataan SQL yang disarankan oleh DBA mengharuskan pemanggilan kode terkait BL lainnya atau SQL yang tidak mengikuti rencana eksekusi normal pernyataan SQL.
Sehubungan dengan ini, konfigurasi, tuning kinerja, dan pengkodean SP menjadi fungsi dari kedalaman dan intensitas data BL untuk pengambilan data. Semakin mendalam dan intensif data BL, semakin banyak Pengembang dan DBA harus berada di halaman yang sama untuk jumlah data dan kekuatan pemrosesan yang diberikan ke Database.
KESIMPULAN
Cara pengambilan data harus selalu melibatkan kubu Pengembang dan DBA. Konsesi harus selalu dibuat seperti apa metode pengkodean dan paradigma pengambilan data dapat bekerja bersama, untuk kecepatan dan efisiensi. Jika persiapan data untuk menangani kode sumber dilakukan hanya satu kali sebelum kode mendapatkan data, DBA harus menentukan penggunaan lean dan mean SQL. Jika BL adalah sesuatu yang tidak selaras dengan DBA, kendali kemudian berada di tangan Pengembang. Inilah sebabnya mengapa DBA harus melihat dirinya sendiri dan bagian dari tim proyek dan bukan pulau bagi dirinya sendiri, sementara Pengembang harus membiarkan DBA melakukan fine tuning dari SQL jika memang diperlukan.
sumber
Ini pertanyaan yang bagus untuk ditanyakan di situs web yang penuh dengan DBA. Semoga sebagian besar jawaban akan "pro" ke arah menjaga database dalam keadaan ACID, dan dengan demikian menjaga logika bisnis dalam database. :-)
Adapun pendapat saya, saya pikir Anda harus menerapkan logika bisnis di kedua aplikasi Anda dan database. Pendekatan ini akan menghabiskan lebih banyak waktu dan uang tetapi saya pikir itu akan memiliki solusi bisnis yang lebih baik secara kualitatif sebagai hasilnya.
sumber
Seperti yang dikatakan Adam Musch di atas, ada lebih banyak pertimbangan di sini untuk penampilan. Penggunaan CPU. Penggunaan memori.
Memblokir hal-hal yang jelas salah untuk sampai ke database.
Ketika Anda semakin dalam saat itulah keputusan harus dibuat. Server DB adalah tempat yang sangat mahal untuk melakukan hal-hal yang dapat dilakukan klien dengan mudah. contoh: memformat data, memformat tanggal, merakit string, dll sisi klien.
Apakah Anda melakukan matematika / pemrosesan di klien atau di server DB? Bagi saya itu tergantung pada kompleksitas dan jumlah catatan yang terlibat. Logika bisnis harus benar-benar dilakukan dalam DB itu sendiri sehingga semuanya diperlakukan dengan cara yang sama.
Anda benar-benar harus membuat API pandangan untuk membaca dan menyimpan procs untuk menulis data ke DB untuk menyelamatkan diri Anda dari sakit kepala di masa depan.
Gunakan kekuatan masing-masing ujung untuk keuntungan Anda.
sumber