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


45

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.


13
Saya juga tertarik jika ada pendukung menempatkan logika aplikasi ke dalam lapisan basis data dapat memberikan metode pengujian unit logika aplikasi itu.
Chris Buckett

@ ChrisB: untuk Oracle ada plunit.com/index.htm
Tony Andrews

10
Logika bisnis tolong, bukan logika aplikasi - tujuannya harus menjadi domain masalah, bukan pilihan teknologi!
Phil Lello

1
@ ChrisB: Saya yakin mereka dapat - mengisi tabel dengan data (Anda harus membuat kelas tiruan di lapisan aplikasi), kemudian memanggil SP secara otomatis dengan skrip. Semuanya bisa ditulis sebagai skrip pernyataan SQL, pembersihan dan pengaturan saat berjalan. Berikut ini tautan untuk 3 alat uji SQL unit: toadworld.com/BLOGS/tabid/67/EntryId/67/…
gbjbaanb

Saya menulis pemikiran saya tentang ini di blog saya baru
Gayus

Jawaban:


38

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.

5
Bisakah kita menambahkan juga kemampuan untuk mengontrol sumber-sumber objek saat mereka dimodifikasi? Mungkin itu hanya keluhan pribadi saya ... (ya, saya jelas mengabaikan cara-cara yang bisa dilakukan ...)
jcolebrand

6
Re: 4. Hebat! Mari kita gunakan logika VB di aplikasi Solaris Java saya ... oh, tunggu ...
Phil Lello

11
Phil, Luar Biasa! Mari kita gunakan logika Oracle Anda di aplikasi SQL Server saya ... oh, tunggu ...
Craig

9
@Craig Kenyataannya adalah bahwa organisasi mengubah vendor basis data jauh lebih jarang daripada mereka beralih aplikasi atau bahasa. Namun, maksud saya lebih dari itu bukan keunggulan aplikasi vs db, bukan bahwa db lebih unggul di sini; ada pro dan kontra dari kedua pendekatan
Phil Lello

1
@ jcolebrand - Nah, jika Anda melakukan pengembangan basis data , maka VS 2010 adalah bomnya. Saya mentransisikan grup kami dari SSMS ke VS untuk pekerjaan pengembangan dan melihat mengadopsi hal TDD ini yang merupakan kemarahan para pengembang. Ini adalah investasi waktu yang berharga untuk setiap toko dengan pekerjaan pengembangan basis data yang signifikan (dan tentu saja, cenderung menggunakan SQL Server).
Nick Chammas

11

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.


4
"tidak semudah dengan kode aplikasi" mengapa tidak?
NimChimpsky

@ Nim - kecuali saya salah melakukannya, ini melibatkan proyek-proyek basis data alih-alih sederhana "sunting dan periksa" Anda dapatkan ketika kontrol sumber terintegrasi ke dalam IDE Anda.
ChrisF

1
Saya kira karena Anda dapat membuat perubahan pada basis data Anda tanpa melakukan itu untuk kontrol versi, tetapi Anda tidak dapat benar-benar melakukan hal yang sama dengan kode ...
Jaco Pretorius

5
@ Jaco Tidak, tetapi Anda dapat menjalankan / melepaskan kode tanpa memasukkannya ke dalam SCM. Manajemen rilis ceroboh adalah manajemen rilis ceroboh teknologi apa pun yang Anda gunakan.
Phil Lello

3
Jika Anda melakukan semua perubahan dengan skrip, maka Anda cukup menyimpannya di direktori kontrol sumber dan check-in dan keluar seperti kode lainnya, Tidak ada alasan mengapa sulit untuk bekerja basis data kontrol sumber.
HLGEM

8

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.


Memperluas ukuran tim cukup sulit tanpa menyertakan seseorang yang tidak mau bekerja sama (tidak yakin mengapa orang yang bertanggung jawab mengizinkan pilihan ini) atau memerlukan 'sesi bimbingan' mereka sendiri untuk mempercepat mereka pada persyaratan.
JeffO

1
Dugaan saya adalah karena mereka sering duduk tanpa melakukan apa-apa, jadi ketika Anda akhirnya memberi mereka sesuatu untuk ditinjau, mereka ingin benar-benar memikat perhatian. Mungkin hanya aku ...
Jaco Pretorius

5
@ Jeff O Mengapa DBA tidak terlibat dalam desain? DBA cenderung tahu lebih banyak tentang pengoptimalan basis data daripada pengembang lain, dan harus diperlakukan sebagai bagian dari tim.
Phil Lello

8
@ Phil Lello: Karena kebanyakan pengembang perangkat lunak adalah arogan yang berpikir bahwa mereka dapat mempelajari semuanya sendiri. Inilah sebabnya mengapa begitu banyak basis data yang merupakan tumpukan sampah.
HANYA PENDAPAT SAYA yang benar

2
Kedengarannya seperti dba Anda membangun pagar di sekitar ladang ranjau untuk membuat Anda tetap aman. Bersyukurlah!
James Anderson

7

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.


Ini. Anda ingin database Anda tangguh. Jadi logika yang terkait dengan data Anda harus berada di sana.
Arkh

6

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.


4
Ini jawaban terbaik. Jika logika bisnis ada dalam aplikasi, maka jika ada beberapa aplikasi menggunakan logika yang berbeda, basis data dapat berakhir dalam keadaan yang sangat buruk.
Sam

5

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.


5
Saya benar-benar tidak mengikuti titik degradasi basis data; dengan meletakkan logika di basis data, Anda hanya perlu mengubah aturan di satu tempat (basis data) tidak banyak aplikasi yang ditulis dalam banyak bahasa. Namun +1 memberi respons yang dipikirkan dengan matang.
Phil Lello

3
Saya harus menunjukkan bahwa banyak pengembang yang berpikir semua logika harus masuk dalam aplikasi termasuk intergritas data di dalamnya. Itulah salah satu alasan mengapa begitu banyak database memiliki integritas data yang buruk. Dan kinerja adalah salah satu dari tiga faktor paling penting untuk sebuah basis data (bersama dengan integritas dan keamanan data), jadi tentu saja kami khawatir tentang itu!
HLGEM

1
Data hanya sebagus aplikasi. Sampah dalam sampah keluar dan semua itu. Jika Anda memiliki, bersenandung, orang yang kurang tepat menulis aplikasi, ada sangat sedikit yang dapat Anda lakukan sebagai DBA untuk memperbaiki sampah.
Christopher Mahan

1
@ChristopherMahan, ada banyak hal yang dapat Anda lakukan dalam desain database untuk mencegah data buruk.
HLGEM

4

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.


Kata baik. Bug besar saya dengan prosedur tersimpan, integritas referensial dll. Adalah penanganan kesalahan. Semua sering pengguna akhir disajikan dengan "objek kesalahan mulsa prosedur YYYY XXXXXX - sqlcode -666" yang menghasilkan waktu yang membuang-buang panggilan dukungan. Ketika "pelanggan tidak memiliki id pajak" sederhana akan membiarkan pengguna memperbaiki masalahnya dan melanjutkan pekerjaannya.
James Anderson

3

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


3
Sangat sulit untuk membangun gudang data agnostik aplikasi dengan logika berbasis aplikasi
Phil Lello

3

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.


2

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?


Semua kode basis data harus berada dalam kendali sumber dalam peristiwa apa pun. Ini adalah kode seperti yang lainnya.
HLGEM

1

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.