Apakah prosedur tersimpan melanggar pemisahan tiga tingkat?

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?

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.

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.

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.

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.

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).

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.