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

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?

Sunting Pertanyaan ini juga tercakup di dba.se , dari perspektif DBA. Karena programmers.se & dba.se memiliki audiens dan bias yang berbeda, pembaca di masa depan mungkin ingin meninjau kedua set jawaban sebelum memutuskan mana yang terbaik bagi mereka.

Dari atas kepala saya, keuntungan menempatkan logika di lapisan aplikasi.

1. Testabilitas . Ini harus menjadi alasan yang cukup baik pada itu sendiri sebenarnya.
2. Struktur kode yang lebih baik . Sangat sulit untuk mengikuti arsitektur OO yang tepat dengan SQL. Ini biasanya juga membuat kode lebih mudah dipelihara.
3. Lebih mudah dikodekan . Karena semua fitur bahasa yang berbeda tersedia dalam bahasa apa pun yang Anda gunakan, biasanya lebih mudah untuk membuat kode di lapisan aplikasi.
4. Kode digunakan kembali . Jauh lebih mudah untuk berbagi kode dengan perpustakaan daripada berbagi kode dalam database.

Meskipun dimungkinkan untuk menggunakan kontrol versi dengan prosedur tersimpan (misalnya alat basis data Redgate berintegrasi dengan TFS), itu tidak selalu lurus seperti halnya dengan kode aplikasi.

Posisi default saya adalah bahwa logika harus dijauhkan dari lapisan database, namun ada kalanya akan lebih efisien untuk mengimplementasikan logika dalam database. Jika itu masalahnya maka Anda harus memastikan Anda dapat melacak perubahan pada kode ini.

Di satu perusahaan tempat saya bekerja, ada banyak birokrasi yang terlibat dengan merilis kode produksi dan melibatkan DBA untuk rilis kode selalu menjadi mimpi buruk. Kami selalu menempatkan logika di lapisan aplikasi untuk menghilangkan keharusan berurusan dengan DBA yang sulit untuk dikerjakan. Itu alasan yang benar-benar lumpuh tetapi berasal dari karena kebutuhan.

Menempatkan logika aplikasi dalam DB terdengar seperti ide yang buruk bagi saya. OTOH menempatkan logika dalam DB yang secara khusus merupakan bagian dari mempertahankan status DB (misalnya pemicu / sprocs untuk memperbarui tabel de-normalisasi) adalah proposisi yang jauh berbeda.

Bergantian, ini dapat dinyatakan sebagai: ada argumen yang baik untuk menempatkan logika yang diperlukan untuk mengabstraksi bagaimana database benar-benar bekerja dari bagaimana Anda ingin melihat ke dalam database.

Setelah membaca kedua pertanyaan itu, saya pikir kita semua mungkin kehilangan satu poin penting. Jawaban yang benar mungkin tergantung pada jenis perangkat lunak yang Anda kembangkan. Kelompok DBA sebagian besar cenderung bekerja pada sistem perangkat lunak Enterprise bisnis yang kritis dan jawaban mereka cenderung mencerminkan apa yang perlu di dunia itu. Ada perbedaan besar dalam apa yang dibutuhkan untuk jenis-jenis aplikasi itu daripada apa yang dibutuhkan untuk aplikasi "Facebook" berikutnya. Bukan masalah besar jika Anda kehilangan beberapa posting di dinding, itu adalah jika Anda kehilangan beberapa pesanan atau transaksi keuangan lainnya.

Orang-orang yang bekerja di dunia COTS (komersial di luar Shelf) cenderung perlu menjadi agnostik basis data untuk alasan penjualan dan mereka menginginkan segala sesuatu dalam kode yang dipatuhi untuk membuatnya lebih sulit untuk merekayasa balik dan mengganti produk mereka dengan yang dibuat sendiri. Aplikasi Enterprise yang dikembangkan dan dipelihara secara internal hampir tidak perlu mengubah backend database kecuali untuk memutakhirkan.

Aplikasi perusahaan juga merupakan aplikasi yang cenderung memiliki input dari banyak tempat dengan database menjadi satu-satunya kesamaan. Sistem tempat saya bekerja memiliki ratusan aplikasi berbeda yang mengaksesnya serta ratusan impor data klien, ekspor data ke klien dan ke gudang data dan menggunakan sistem pelaporan mulitple. Kode yang berfungsi dengan baik ketika menambahkan satu catatan gagal ketika saya harus mengimpor 20.000.000. Kami terpaksa menggunakan lapisan aplikasi sekali karena di situlah logikanya dan harus menghentikan proses 18 jam kemudian yang belum selesai. Logika yang berlaku untuk semua rekaman data dalam tabel harus di database ketika Anda tidak bisa memiliki satu lapisan data yang digunakan semua orang.

Sebaliknya ketika hanya satu aplikasi yang akan mengkonsumsi data dan data tersebut bukan urat nadi perusahaan Anda atau penekanan, aturannya berbeda dan menempatkan semua logika dalam aplikasi lebih masuk akal.

Gondrong. lihat Ringkasan di bawah.

RDBMS

RDBMS adalah singkatan dari sistem manajemen basis data relasional. Ini adalah sistem untuk mengelola basis data relasional. Data disimpan di sana. Data. Itu tidak mengatakan logika bisnis.

Proses bisnis

Apa yang dimaksud dengan logika bisnis? Bagi saya, ini deskripsi proses bisnis secara logis.

Proses adalah aktivitas bisnis yang terjadi secara teratur, cukup sehingga tidak lagi bersifat ad hoc. Ini berbeda untuk setiap bisnis.

Biarkan saya mengenakan topi bisnis saya dan menjelaskan apa artinya bisnis di sini. Bagi sebagian orang, ini mungkin mengejutkan.

Bisnis

Bisnis adalah jumlah dari kegiatan yang dilakukan untuk mencapai penciptaan nilai, dan lebih khusus lagi nilai yang dapat diperdagangkan. Ini bisa berarti membuat pemanen gabungan, sandwich tuna, atau menyediakan layanan perbankan. Di sebagian besar negara di dunia, bahkan yang berada dalam sistem non-kapitalistik, orang suka mendapatkan nilai terbaik untuk uang mereka, dan karena itu ada persaingan antara penyedia barang dan jasa yang berharga ini. Persaingan umumnya bergantung pada harga, kualitas, dan ketersediaan.

Jalan memutar cepat: Anda membutuhkan 40 juta paku keling dalam 2 hari, Anda tidak akan memesan dari seseorang di internet dengan akun paypal, tidak peduli berapa jauh lebih murah harganya daripada penjual normal Anda.

Memproses Pengetahuan

Seperti yang dapat Anda bayangkan, proses yang terlibat dalam membuat "nilai" ini sebagian besar hidup di kepala eksekutif. Beberapa di antaranya diletakkan di atas kertas dan digunakan sebagai kebijakan dan prosedur perusahaan. Beberapa di antaranya hidup di kepala penasihat perusahaan. Banyak yang hidup di kepala orang-orang yang menjalankan divisi, departemen, tim, dan mereka yang menjalankan mesin, mesin kasir, oven, truk. Sebagian kecil yang membuatnya turun pada persyaratan bisnis untuk perangkat lunak, dan bagian yang lebih kecil dari itu akurat pada saat itu diterapkan dalam sistem komputer.

Pada akhirnya, logika bisnis yang Anda lihat dalam kode bukanlah yang menjalankan bisnis, melainkan yang menjalankan aplikasi untuk bisnis. Otak yang sebenarnya di dalam orang yang sebenarnya memegang proses bisnis yang sebenarnya, dan mereka tidak memiliki masalah memahami bahwa proses di otak mereka lebih akurat daripada proses di komputer. Selain itu, Anda mungkin tidak dapat menjalankan bisnis jika yang Anda miliki hanyalah kebijakan dan prosedur sebagian besar perusahaan. Sangat sering ini sangat tidak akurat, meskipun ada upaya yang sangat besar.

Jadi pada akhirnya, itu adalah logika aplikasi yang dikodekan ke dalam perangkat lunak. Dan orang-orang ingin memasukkannya ke dalam basis data, karena vendor sistem manajemen basis data telah membuat klaim besar.

Logika Aplikasi

Aku bilang tidak. Saya katakan logika aplikasi tetap di dalam aplikasi. Data masuk ke dalam database, dengan cara yang sangat normal, dan kemudian membawa ETL ke rumah dataware untuk melaporkan dan mengebor dan rolluping dan pivoting dan cubing.

Data

Saya juga mengatakan bahwa data hidup lebih lama dari aplikasi, jadi upaya normalisasi data tidak boleh spesifik aplikasi, dan bahkan tidak khusus bisnis, tetapi harus bisnis-umum. Apakah Anda menyimpan kode negara? Anda harus menggunakan INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) karena itu portabel di seluruh bisnis. Ini juga memudahkan banyak aplikasi untuk memanipulasi data.

NoSQL?

Jika Anda memperlakukan database sebagai bagian dari kode aplikasi, dari tata letak tabel hingga pemicu, prosedur tersimpan, dan format data, Anda pada dasarnya menggunakan database perusahaan sebagai BerkleyDB yang dimuliakan, yang merupakan struktur file flat yang dimuliakan, yang benar-benar hanya daftar bertahan. Ini pada dasarnya adalah apa yang dilakukan NoSQL: kembali ke akar, tetapi melakukannya dengan multi-proses, bertahan, dengan cara yang toleran terhadap kegagalan.

Kode Aktual

Tidak, Anda perlu memperlakukan basis data sebagai tempat penyimpanan data umum untuk banyak aplikasi, baik saat ini dan di masa depan. Sekarang kita sampai pada inti argumen saya. Proses bisnis berubah dengan keanehan pasar, politik, dan mode. Sangat sering mereka berubah lebih cepat dari apa yang dapat dikelola oleh pembuat kode dengan bahasa kelas sains komputer (Java, C #, C ++ dll) dan akhirnya ditulis dalam VBA dalam spreadsheet excel di departemen akuntansi atau pemasaran. (Dan hanya jika itu tidak bisa diungkapkan dalam vlookup mewah ...)

Degradasi basis data

Data tidak banyak berubah jika terorganisir dengan baik. Logika bisnis berubah sangat cepat. Dengan memasukkan logika bisnis ke dalam basis data, Anda membuat basis data menjadi kurang berharga, karena akan menjadi usang dan tidak akurat lebih cepat.

Ringkasan

Data harus hidup lebih lama dari aplikasi karena proses bisnis hidup dalam aplikasi dan proses bisnis berubah lebih sering. Termasuk logika bisnis dalam database buruk untuk umur panjang dan nilai keseluruhan.

Peringatan

Saya telah melakukan bagian saya dari dba-ing dan saya sudah membaca jawaban di dba.se tetapi dalam semua kejujuran apa yang mereka bicarakan adalah masalah integritas data dan masalah kinerja. Saya sepenuhnya setuju bahwa orang yang menyentuh data perusahaan harus tahu apa yang mereka lakukan, apakah dba atau programmer atau analis senior SAS dengan akses baca / tulis.

Saya juga mencatat bahwa mereka merekomendasikan coders tahu SQL. Saya setuju. Ini adalah bahasa pemrograman komputer, jadi saya tidak melihat mengapa pemrogram komputer tidak ingin mengetahuinya.

Kemudian, setelah memikirkannya

Saya pikir jalan tengahnya adalah membuat API, dan meminta API untuk mengatur aliran data ke sana kemari. Jika Anda tidak dapat mengizinkan aplikasi terhubung langsung ke tabel, setidaknya Anda dapat membuat mekanisme akses dalam bahasa modern.

Berisiko terdengar dramatis, saya benar-benar ngeri dengan gagasan logika aplikasi dalam database. Banyak jawaban di sini berfokus pada keunggulan pengembangan perangkat lunak, jadi demi singkatnya, saya akan fokus pada keuntungan yang dihasilkan oleh pembagian tanggung jawab.

Database menyediakan cara yang efisien untuk menyimpan dan mengakses informasi, sambil meminimalkan data yang berlebihan dan menghasilkan hubungan logis dalam data. Walaupun logika basis data mungkin mampu menerapkan logika bisnis tingkat produksi, pendapat pribadi saya adalah bahwa basis data harus sama agnostik aplikasi untuk memastikan bahwa data dapat secara efektif dimanfaatkan oleh berbagai aplikasi sambil bermain sesuai kekuatan masing-masing basis data mesin versus kekuatan bahasa implementasi aplikasi.

Satu pengguna di pertukaran tumpukan DBA menyatakan ini ...

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.

... Diikuti oleh keyakinannya bahwa ini merupakan indikasi pelanggaran prinsip KERING.

Daripada menjadi pengulangan logika bisnis, saya pikir ini lebih merupakan contoh sempurna dari fleksibilitas yang diberikan oleh pembagian tanggung jawab yang berbeda antara lapisan bisnis dan lapisan data.

Database OLTB mereka telah menyediakan data dengan andal dan efisien untuk 25+ aplikasi selama beberapa dekade! Itu luar biasa! (Jalan untuk pergi!)

Saya hanya dapat berasumsi bahwa data tersebut cukup agnostik untuk menyediakan konten untuk sejumlah aplikasi yang berbeda. Sesuatu yang sebagian besar tidak mungkin jika para pengembang itu mencoba meretas sesuatu bersama-sama menggunakan logika database.

Seperti yang ditunjukkan oleh jawaban lain, ada banyak alasan lain untuk tidak mengimplementasikan program dalam database. Saya yakin itu akan berhasil, tetapi hasil yang paling mungkin adalah puluhan tahun penyesalan, bukan stabilitas selama beberapa dekade.

Database aplikasi agnostik membutuhkan semua logika dari database. Sangat sulit untuk membangun dan memelihara kode ke banyak penyedia basis data yang berbeda.

Perkembangan yang baik akan memberikan keseimbangan yang baik antara kebutuhan akan integritas dan kecepatan basis data dengan memasukkan sebagian logika ke dalam basis data dan sebagian besar dalam aplikasi.

Apakah kueri yang sama akan digunakan berulang kali di banyak aplikasi, maka mungkin itu termasuk dalam prosedur tersimpan.

Memastikan bahwa bidang pemeliharaan rumah ditetapkan ketika baris dimasukkan dan diperbarui adalah tanggung jawab DBA. Pemicu akan digunakan.

Di sisi lain, jika saya memiliki logika bisnis, harus ada dalam aplikasi. Seharusnya jika memungkinkan melakukan panggilan ke prosedur tersimpan yang akan mengembalikan catatan yang diinginkan, difilter diatur dengan jumlah bidang yang dibutuhkan. Tidak lebih, tidak kurang.

Ini masalah komunikasi antara tim dan masalah mengakui pro dan kontra untuk setiap kemungkinan.

Pendapat saya adalah: Jangan membuat logika aplikasi terlalu dalam di DB.

Beberapa sistem perdagangan menyediakan cara untuk memperluas fungsionalitas yang ada dengan skrip, pada dasarnya dimasukkan ke dalam basis data. Pengalaman saya dengan ini agak negatif, setidaknya dalam pengaturan multi-pengguna.

Anda memasukkan logika ke dalam basis data, karena Anda ingin dapat memodifikasi logika itu dengan mudah.

• Bagaimana Anda melakukan kontrol versi?
  • Apa sejarah kode? Apa saja perubahannya? Oleh siapa?
  • Bagaimana Anda menangani perubahan pada fragmen kode yang sama?
• Bagaimana Anda mengidentifikasi dan menjamin status kode yang konsisten?

Anda bisa melacak ini di VCS berbasis file tambahan, tapi lalu apa manfaat dari database?

Sebagian besar aplikasi perlu memiliki beberapa cara untuk menyediakan integrasi. Idealnya, Anda akan memiliki API lengkap, layanan web atau setidaknya menyediakan beberapa objek database yang berisi logika bisnis. Setiap orang tidak dalam posisi waktu / sumber daya untuk membangun API, jadi Anda harus berkompromi.