Apa argumen yang menentang atau untuk menempatkan logika aplikasi di lapisan basis data?

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.

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

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?

Saya memindahkan jawaban lama saya ke yang belum diedit dari programmer.se, karena jawaban tampaknya cukup terpolarisasi di antara beberapa situs.

Saya tahu saya berada di dunia yang terluka di sini, tetapi memasukkan logika bisnis ke dalam basis data karena:

• Anda dapat memungkinkan pengguna bisnis kekuatan akses langsung ke database dan tidak khawatir tentang mereka mengacaukannya (atau khawatir kurang dari yang Anda lakukan dengan logika berbasis aplikasi)
• Seorang pengguna yang kuat dapat membuat laporan baru tanpa menunggu rilis perangkat lunak baru.
• Anda dapat menguji kode SP / TRIGGER dalam salinan database, sama seperti Anda menguji logika berbasis aplikasi
• Anda dapat menyimpan SQL untuk membuat sp dan pemicu dalam file teks (Anda tetap harus melakukan ini untuk tabel / kode tampilan)
• Anda dapat mencampur dan mencocokkan bahasa tanpa porting logika bisnis
• Anda dapat membuat perubahan pada logika bisnis tanpa memutakhirkan setiap bit perangkat lunak
• Struktur audit Anda berubah dengan cara yang sama seperti Anda mengaudit aktivitas basis data - melalui pencatatan
• Keamanan yang sangat ditingkatkan dan kontrol akses berbutir halus (sebagian besar implementasi logika berbasis aplikasi menggunakan model keamanan mereka sendiri, sehingga data jauh lebih mudah untuk dikompromikan. Enkripsi kata sandi yang dapat dibalik tidak jarang terjadi)
• Keamanan pengguna sisi database sangat mengurangi kerusakan / pencurian nakal yang dapat dilakukan SQL

Kontra adalah: - Pengembang terancam ketika pengguna menjadi kurang bergantung pada pengembang untuk laporan khusus - Pengembang perlu mempelajari bahasa pemrograman lain

Tak satu pun dari mereka yang penting bagi pengembang yang terampil.

Menarik untuk dicatat, sebagian besar jawaban berbicara dalam hal 'logika aplikasi', bukan 'logika bisnis', seolah-olah perangkat lunak tidak ada di sana untuk menyediakan fungsi bisnis.

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

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.

...
3. Tambahkan integritas / periksa kendala ke database yang mendasarinya,dengan kode yang lebih kompleks diimplementasikan dalam bahasa prosedur tersimpan dalam database. Dari ini kita mendapatkan satu lokasi pusat untuk dipertahankan dan kita mendapatkan penegakan aturan mutlak bahkan untuk aplikasi yang kita tidak tahu! Kami mendapatkan satu bahasa untuk mengekspresikan aturan bisnis, di seluruh portofolio aplikasi dan siklus hidup, karena bahasa du jour berubah jauh lebih sering daripada database. Dan itu berjalan pada sistem yang sudah sama kritisnya dengan aplikasi yang paling penting. Kesalahan ditangani oleh kode yang ada yang menangani kesalahan basis data di aplikasi tersebut. Masih ada risiko bahwa suatu aplikasi mungkin rusak tentu saja, tetapi dari tiga skenario, ini adalah yang paling sedikit, dan hanya aplikasi yang rusak membutuhkan modifikasi, tidak semuanya (dan sebagian besar mekanisme SP / database akan memungkinkan pengecualian dibuat untuk satu aplikasi jika itu benar-benar diperlukan). Pikirkan ini tidak masalah di situs greenfield atau perusahaan kecil Anda? Nah jika bisnis Anda berhasil, dalam waktu 30 tahun Anda akan berharap Anda telah memperhatikan kebijaksanaan saya!

… Beberapa [keberatan] yang sering saya dengar:

• Sulit untuk mengontrol kode SP versi yang digunakan dalam DB. Saya tidak berpikir itu lebih benar daripada mengatakan sulit untuk mengontrol kode Java versi yang digunakan di server aplikasi, yang berarti, tidak sulit sama sekali, itu biasa. Dan di Ruby-land, seluruh buku ditulis tentang bagaimana cara mendapatkan kode Anda dari lingkungan pengembangan menjadi produksi, sesuatu yang tampaknya tidak ada kesulitan dengan komunitas bahasa lain. Namun versi yang mengontrol prosedur yang tersimpan tampaknya terlalu sulit.
• Prosedur yang tersimpan sulit untuk diuji. Ini aneh. Sebagai permulaan, SP diketik dengan kuat; kompiler akan memberi tahu Anda jika ada jalur kode masuk atau keluar yang tidak masuk akal, dan di Oracle setidaknya, akan menghitung semua dependensi untuk Anda. Jadi itu satu set tes unit umum yang mungkin Anda butuhkan di Ruby dihilangkan kelelawar. Untuk menguji kode OO diperlukan mengejek untuk memaksa objek ke keadaan internal yang diperlukan untuk mewakili skenario pengujian - bagaimana menyiapkan data uji berbeda? Ada produsen TAP untuk PL / SQL dan alat-alat lainnya. Ada juga debugger dan profiler.
• Bahasa prosedur tersimpan bukan bahasa berfitur lengkap. Yah, kami tidak mencoba untuk menulis seluruh aplikasi hanya dalam prosedur tersimpan! Sebagian besar bahasa SP berdedikasi memiliki semua konstruksi modern yang Anda harapkan, dan setidaknya di Oracle, Anda dapat menggunakan Java Stored Procedures dengan semua fitur bahasa yang dikenal oleh pengembang OO, atau prosedur eksternal dalam bahasa apa pun. Yang penting adalah di mana logika diterapkan - di satu tempat, dekat dengan data - bahasa sebenarnya hanyalah detail. PL / SQL mengkompilasi ke kode asli dan berjalan dalam proses dengan database; tidak ada arsitektur berkinerja lebih tinggi dari itu.
• Saya tidak mau harus belajar bahasa lain. Menghindari sedetik pun, ini adalah bendera merah besar di pengembang mana pun (terutama yang mengusulkan memodifikasi aplikasi produksi yang mungkin dalam bahasa lain!) Ada banyak yang harus dipelajari untuk bekerja di lingkungan modern apa pun: toko Java yang khas mungkin memiliki Eclipse , WebLogic, Maven, Hudson, Anthill, Subversion, dan sejumlah besar lainnya, yang perlu Anda pelajari sebelum menulis satu baris kode aplikasi. Pengetahuan kerja bahasa SP tingkat sangat tinggi sangat mudah dibandingkan, dan kemungkinan besar akan ada spesialis atau DBA di sekitar untuk membantu Anda juga. Belum lagi Hibernate favorit pengembang hadir dengan bahasa permintaan sendiri ...

...

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)

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.

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.

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.

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.

• Menyingkirkan alamat email yang tidak sesuai dengan beberapa cara dasar.
• Periksa panjang

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.