Apakah prosedur tersimpan melanggar pemisahan tiga tingkat?


41

Beberapa rekan saya mengatakan kepada saya bahwa memiliki logika bisnis dalam prosedur tersimpan dalam database melanggar arsitektur pemisahan tiga-tier, karena database milik lapisan data sedangkan prosedur tersimpan adalah logika bisnis.

Saya pikir dunia akan menjadi tempat yang sangat suram tanpa prosedur yang tersimpan.

Apakah mereka benar-benar melanggar pemisahan tiga tingkat?


9
Tanyakan saja kepada mereka apakah mereka belum pernah mendengar tentang arsitektur tingkat 3 1/2 ...
dreza

7
Ingatlah bahwa tingkatan dan lapisan bukan satu dan sama.
NoChance

2
@ emmad-kareem Pertanyaan ini membantu saya ( stackoverflow.com/questions/120438/… ). Masalahnya adalah bahwa literatur teknis bahasa Spanyol (bahasa ibu saya) menggunakan satu kata untuk itu ("capa"), sedangkan bahasa Inggris memiliki dua kata yang sangat berbeda.
Tulains Córdova

1
@ user1598390, Anda benar itu bisa membingungkan terutama bahwa dunia perangkat lunak tidak punya cukup ketelitian ketika datang ke definisi dalam satu bahasa apalagi lintas bahasa.
NoChance

1
Arsitektur 3-Tier adalah konsep logis, bukan konsep fisik. Anda dapat menerapkan aturan bisnis menggunakan prosedur yang tersimpan, dan sementara secara fisik di dalam database, prosedur yang tersimpan tersebut masih menjadi bagian dari tingkat logika bisnis.
Craig

Jawaban:


33

Rekan Anda menggabungkan arsitektur dengan implementasi.

Gagasan di balik aplikasi multi-tiered hanyalah bahwa itu dipecah menjadi bagian-bagian yang merangkum beberapa jenis pemrosesan (penyimpanan, logika bisnis, presentasi) dan berkomunikasi satu sama lain menggunakan antarmuka yang terdefinisi dengan baik. Sama seperti mungkin untuk berhasil melakukan hal-hal yang menyerupai pemrograman berorientasi objek dalam bahasa-bahasa yang tidak berorientasi objek, dimungkinkan untuk melakukan hal yang sama dengan beberapa tingkatan dalam satu lingkungan, seperti server database. Kesamaan apa yang dimiliki salah satu dari mereka yang berhasil adalah kebutuhan akan perawatan, disiplin, dan pemahaman tentang kompromi yang terlibat.

Mari kita lihat aplikasi tiga tingkat di mana dua tingkatan telah diimplementasikan pada basis data:

  • Data Tier: Terdiri dari tabel database diakses menggunakan empat operasi meja standar ( INSERT, UPDATE, DELETEdan SELECT).
  • Tingkat Logika: Terdiri dari prosedur tersimpan yang hanya menerapkan logika bisnis dan mengakses tingkat data hanya menggunakan metode yang diuraikan di atas.
  • Tingkat Presentasi: Terdiri dari kode server yang menjalankan web yang mengakses tingkat logika dengan hanya membuat panggilan prosedur yang tersimpan.

Ini adalah model yang benar-benar dapat diterima, tetapi disertai dengan beberapa pengorbanan. Logika bisnis diimplementasikan dengan cara yang memberikan akses cepat dan mudah ke tingkat data dan memungkinkan melakukan hal-hal yang harus dilakukan "dengan cara yang sulit" oleh tingkat logika di luar basis data. Apa yang Anda menyerah adalah kemampuan untuk dengan mudah memindahkan tier ke beberapa teknologi lain dan implementasi tanpa beban (yaitu, Anda harus ekstra hati-hati karena tingkatan tidak menggunakan fasilitas yang tersedia dalam database tetapi di luar antarmuka yang ditentukan mereka) .

Apakah hal ini dan pengorbanannya dapat diterima dalam situasi tertentu adalah sesuatu yang Anda dan rekan Anda harus tentukan dengan menggunakan penilaian Anda.


2
Jadi saya dapat mengatakan kepada mereka bahwa prosedur tersimpan adalah bagian dari tingkat logika, arsitektur-bijaksana, terlepas dari kenyataan bahwa mereka disimpan dalam database?
Tulains Córdova

3
@ user1598390: ya. Meskipun itu akan menjadi layer untuk mengatakan 3-layer, dan bukan 3 tier.
jmoreno

4
@ user1598390: Anda bisa mengatakan itu selama Anda bisa membuktikannya. Pertama kali layer presentasi SELECTlangsung dari tabel (tier data), model telah rusak.
Blrfl

@blrfl Itu sesuatu yang sudah saya
urus

2
@ user1598390: tidak apa-apa, ingat saja bahwa tujuannya adalah pemisahan logis dari masalah, bukan meletakkan berbagai hal pada perangkat keras yang berbeda.
jmoreno

19

Prosedur tersimpan cukup kuat untuk memungkinkan Anda mengkode pelanggaran pemisahan tiga tingkat dengan membawa logika bisnis ke dalam lapisan RDBMS. Namun, ini adalah keputusan Anda, bukan cacat prosedur tersimpan yang melekat. Anda dapat membatasi SP Anda untuk melayani kebutuhan lapisan data Anda, sambil menjaga logika aplikasi Anda di lapisan aplikasi arsitektur Anda.

Ada pengecualian yang jarang namun penting untuk aturan pemisahan, ketika Anda membutuhkan prosedur tersimpan (khususnya, sekelompok pemicu) untuk mengandung logika bisnis. Ini terjadi ketika aplikasi Anda perlu menghasilkan banyak agregasi data on-the-fly yang menyentuh jutaan baris. Dalam kasus seperti itu, pemicu dapat diatur untuk mempertahankan data pra-agregat untuk penggunaan lapisan bisnis. Ini harus dilakukan hanya dalam situasi ketika tanpa pra-agregasi aplikasi Anda akan sangat lambat.


7
+1 untuk menyebutkan bahwa kadang-kadang Anda ingin beberapa logika untuk hidup dalam database karena alasan kinerja karena RDBMS umumnya akan melakukan set perintah operasi yang besarnya lebih cepat dari kode aplikasi Anda. Meskipun jelas ini hanya ketika kinerja sangat penting dan tidak dapat dipenuhi dalam kode aplikasi, sebagian besar aplikasi yang didukung database modern adalah aplikasi CRUD dan tidak menggunakan untuk manfaat seperti itu.
Jimmy Hoffa

1
Amin. Orang-orang tampaknya berpikir bahwa sprocs = bisnis "kode". Mereka harus dianggap sebagai 'API' DB, dan kemudian mereka lebih masuk akal. Tentu saja, mereka juga dapat memperbaiki kasus tepi di mana Anda memerlukan kinerja dari logika Anda juga!
gbjbaanb

5

Saran Atwood dari tahun 2004 masih berlaku hingga hari ini, hanya saja kami sekarang memiliki manfaat dari ORM juga.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

Prosedur Tersimpan harus dianggap sebagai bahasa rakitan basis data: untuk digunakan hanya dalam situasi paling kritis kinerja. Ada banyak cara untuk mendesain lapisan akses data yang solid dan berkinerja tinggi tanpa menggunakan Prosedur Tersimpan; Anda akan menyadari banyak manfaat jika Anda tetap menggunakan SQL yang diparameterisasi dan satu lingkungan pengembangan yang koheren.


Dalam pengalaman saya selama 20 tahun di sebuah perusahaan besar, prosedur tersimpan tidak digunakan untuk mengembalikan baris (tampilan digunakan untuk itu), juga tidak digunakan untuk setiap sisipan atau pembaruan sederhana (sql inline digunakan untuk itu). Mereka digunakan sebagian besar untuk operasi panjang yang tidak memerlukan interaksi pengguna, membutuhkan pengulangan set besar data untuk meringkas dan melakukan memasukkan atau memperbarui berdasarkan beberapa logika bisnis, pada basis baris, seperti penutupan akhir ngengat atau pemrosesan batch transaksi harian . Penulis artikel tampaknya menggunakan prosedur tersimpan untuk mengembalikan baris dan itulah sebabnya ia memanaskannya.
Tulains Córdova

3

Ringkasan Singkat: Ini benar-benar tergantung pada penggunaan prosedur tersimpan dan persyaratan bisnis Anda.

Ada sejumlah proyek yang menggunakan arsitektur three-tier dan tergantung pada sifat persyaratan bisnis mungkin ada kebutuhan untuk mengalihkan beberapa operasi ke tier data.

Berbicara tentang terminologi, secara umum tingkatan ini digambarkan sebagai:

  • Tingkat presentasi , atau lapisan layanan pengguna - memberikan akses pengguna ke aplikasi.
  • Lapisan menengah , atau lapisan layanan bisnis - terdiri dari aturan bisnis dan data.
  • Tingkat data , atau lapisan layanan data - berinteraksi dengan data persisten yang biasanya disimpan dalam database atau dalam penyimpanan permanen.

Biasanya untuk arsitektur yang diberikan, lapisan menengah atau lapisan layanan bisnis, terdiri dari aturan bisnis dan data. Namun, kadang-kadang membuat perbedaan besar untuk menggeser operasi basis set yang berat dan / atau aturan data yang harus dilakukan dalam tingkat data - melalui serangkaian prosedur yang tersimpan.

Manfaat dari desain tiga tingkat adalah:

Selama siklus hidup aplikasi, pendekatan tiga tingkat memberikan manfaat seperti usabilitas, fleksibilitas, pengelolaan, pemeliharaan, dan skalabilitas. Anda dapat membagikan dan menggunakan kembali komponen dan layanan yang Anda buat, dan Anda dapat mendistribusikannya di jaringan komputer sesuai kebutuhan. Anda dapat membagi proyek-proyek besar dan kompleks menjadi proyek-proyek yang lebih sederhana dan menugaskan mereka untuk programmer atau tim pemrograman yang berbeda. Anda juga dapat menggunakan komponen dan layanan di server untuk membantu mengikuti perubahan, dan Anda dapat menggunakannya kembali seiring pertumbuhan basis pengguna aplikasi, data, dan volume transaksi yang meningkat.

Jadi, ini benar-benar merupakan pendekatan kasus-dasar yang memiliki trade-off sendiri. Namun, pedoman desain Microsoft dari Three-Tier Architecture Model merekomendasikan untuk menjaga logika bisnis Anda di tingkat menengah.


2

Tier sebenarnya berarti mesin yang berbeda, layer berarti pemisahan logis yang berbeda. Dengan prosedur tersimpan Anda memiliki lapisan data dan (setidaknya bagian dari) lapisan logika bisnis di tingkat yang sama. Menempatkan logika bisnis dalam prosedur tersimpan melanggar arsitektur 3-lelah tetapi dipertanyakan apakah melanggar arsitektur 3-lapis; satu hal yang pasti adalah bahwa itu jelas bukan contoh yang baik dari pemisahan kekhawatiran.

Lapisan adalah mekanisme penataan logis untuk elemen-elemen yang membentuk solusi perangkat lunak Anda; tier adalah mekanisme penataan fisik untuk infrastruktur sistem. ( Referensi )

Menurut pendapat saya ada dua masalah utama dengan membangun logika bisnis dalam database:

  1. Kode dan pustaka: Anda akan menemukan lebih sedikit pemrogram yang dapat memprogram dalam SQL, PL / SQL, TSQL dll. Daripada dalam C #, Java, dll. Bahasa pemrograman juga memiliki keunggulan dari IDE yang hebat, perpustakaan dan kerangka kerja yang hebat.

  2. Skalabilitas horisontal: satu-satunya cara Anda dapat skala sistem Anda adalah dengan mengubah server fisik di mana database dengan yang lebih kuat, yang agak mahal (server dengan 64 GB RAM); skala basis data relasional secara horizontal sangat buruk, dan bahkan dengan biaya yang lebih besar. Sementara, dengan logika bisnis di OO-built server Anda dapat mengatur skala secara horizontal dengan menempatkan server pada banyak node (di Jawa banyak server aplikasi mendukung ini).


-1

Kami memiliki debat ini di kantor kami beberapa waktu lalu, saya mendukung Pengembangan Database, saya telah mengikuti pandangan tentang itu

  1. Jika Anda menggunakan Oracle Database, Anda harus menggunakan PL / SQL sebanyak mungkin, karena pasti perusahaan yang berinvestasi akan tetap menggunakan oracle setidaknya 10 tahun dari sekarang. Sementara di aplikasi kemarin Anda menggunakan Oracle Forms, hari ini .net formulir web, lalu MVC, maka besok Anda akan menggunakan angularjs dan hanya perlu aplikatif restfull. Jika logika maksimum Anda ada dalam database, Anda dapat dengan mudah bermigrasi ke teknologi ujung depan yang baru.
  2. Pengembangan basis data sangat cepat dan kinerja yang sangat efisien. Hanya untuk memberi Anda prospek. Dalam proyek kami ada 7 pengembang aplikasi dan satu pengembang basis data, dan 80% dari logika ada di dalam basis data.
  3. Jika Anda menggunakan oracle, Anda dapat menggunakan utilitas untuk secara langsung mengubah prosedur basis data Anda menjadi Res full Api.

Argumen terkuat pengembang aplikasi memberikannya bahwa logika bisnis harus independen dari database sehingga Anda dapat dengan mudah mengubah database. Saya pikir jika sebuah perusahaan menggunakan oracle mengapa mereka akan beralih ke teknologi lain, bukannya peluang mendapatkan logika aplikasi usang lebih diharapkan. Masalahnya adalah kebanyakan bakat baru dari sumber daya database kurang, kebanyakan orang mulai situs web sederhana di mana mereka menggunakan mysql atau sqlserver. Orang-orang ini kemudian menjadi pemimpin senior dan memiliki ikatan emosional dengan lapisan aplikasi :) mereka bahkan tidak ingin mengerti atau berdebat.


"Jika Anda menggunakan Oracle Database, Anda harus menggunakan PL / SQL sebanyak mungkin," Prosedur yang tersimpan menambah beban pada apa yang biasanya merupakan sistem yang paling berleher botol dan sulit dalam skala dalam arsitektur. Mereka juga kesulitan mengelola dari kontrol versi dan perspektif unit-testing "Karena pasti perusahaan yang berinvestasi akan tetap berpegang pada oracle setidaknya 10 tahun dari sekarang." Ini hanya omong kosong. Apa yang membuatmu berpikir demikian? Jika Anda mengisi sistem Anda dengan sampah prosedural PL / SQL bodoh, Anda mungkin membuat perusahaan tidak pindah ke sesuatu yang kontemporer. Itu mungkin benar.
JimmyJames
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.