Singkatnya, saya setuju dengan CTO Anda. Anda mungkin mendapatkan beberapa kinerja dengan mengorbankan skalabilitas (jika persyaratan tersebut membingungkan, saya akan menjelaskan di bawah). Dua kekhawatiran terbesar saya adalah pemeliharaan dan kurangnya opsi untuk menskalakan secara horizontal (dengan asumsi Anda akan membutuhkannya).
Kedekatan dengan data: Mari kita mundur. Ada beberapa alasan bagus untuk memasukkan kode ke dalam DB. Saya berpendapat bahwa yang terbesar adalah kedekatan dengan data - misalnya, jika Anda mengharapkan perhitungan mengembalikan sejumlah nilai, tetapi ini adalah kumpulan dari jutaan rekaman, mengirimkan jutaan rekaman (sesuai permintaan) melalui jaringan yang akan dikumpulkan di tempat lain sangat boros, dan dapat membunuh sistem Anda dengan mudah. Setelah mengatakan ini, Anda bisa mencapai kedekatan data ini dengan cara lain, pada dasarnya menggunakan cache atau DB analisis di mana beberapa agregasi dilakukan dimuka.
Performa kode dalam DB:Efek kinerja sekunder, seperti "caching rencana eksekusi" lebih sulit untuk diperdebatkan. Terkadang, rencana eksekusi yang di-cache bisa menjadi hal yang sangat negatif, jika rencana eksekusi yang salah di-cache. Bergantung pada RDBMS Anda, Anda mungkin mendapatkan yang terbaik dari ini, tetapi Anda tidak akan mendapatkan terlalu banyak dari parametrised SQL, dalam banyak kasus (rencana tersebut biasanya di-cache juga). Saya juga berpendapat bahwa sebagian besar bahasa yang dikompilasi atau JIT'ed biasanya berkinerja lebih baik daripada setara SQL mereka (seperti T-SQL atau PL / SQL) untuk operasi dasar dan pemrograman non-relasional (manipulasi string, loop, dll), jadi Anda tidak akan akan kehilangan apa pun di sana, jika Anda menggunakan sesuatu seperti Java atau C # untuk melakukan angka-angka. Optimalisasi berbutir halus juga cukup sulit - pada DB, Anda sering terjebak dengan pohon-B generik (indeks) sebagai satu-satunya struktur data Anda. Agar adil, analisis lengkap, termasuk hal-hal seperti memiliki transaksi yang berjalan lebih lama, eskalasi kunci, dll, dapat mengisi buku.
Maintainability: SQL adalah bahasa yang luar biasa untuk apa ia dirancang untuk dilakukan. Saya tidak yakin ini sangat cocok untuk logika aplikasi. Sebagian besar perkakas dan praktik yang membuat hidup kita tertahankan (TDD, refactoring, dll) sulit diterapkan pada pemrograman basis data.
Kinerja versus skalabilitas:Untuk memperjelas persyaratan ini, maksud saya ini: kinerja adalah seberapa cepat Anda akan mengharapkan satu permintaan untuk melalui sistem Anda (dan kembali ke pengguna), untuk saat ini dengan asumsi beban rendah. Ini akan sering dibatasi oleh hal-hal seperti jumlah lapisan fisik yang dilaluinya, seberapa baik lapisan tersebut dioptimalkan, dll. Skalabilitas adalah bagaimana perubahan kinerja dengan meningkatnya jumlah pengguna / beban. Anda mungkin memiliki kinerja sedang / rendah (katakanlah, 5 detik + untuk permintaan), tetapi skalabilitas luar biasa (dapat mendukung jutaan pengguna). Dalam kasus Anda, Anda mungkin akan mengalami kinerja yang baik, tetapi skalabilitas Anda akan dibatasi oleh seberapa besar server yang dapat Anda bangun secara fisik. Pada titik tertentu, Anda akan mencapai batas itu, dan dipaksa untuk beralih ke hal-hal seperti sharding, yang mungkin tidak layak tergantung pada sifat aplikasi.
Optimasi Prematur: Pada akhirnya, saya pikir Anda telah membuat kesalahan dengan mengoptimalkan secara prematur. Seperti yang telah ditunjukkan orang lain, Anda tidak benar-benar memiliki pengukuran yang menunjukkan bagaimana pendekatan lain akan bekerja. Ya, kami tidak selalu dapat membuat prototipe skala penuh untuk membuktikan atau membantah teori ... Tapi secara umum, saya selalu ragu untuk memilih pendekatan yang memperdagangkan perawatan (mungkin kualitas aplikasi yang paling penting) untuk kinerja .
EDIT: Pada catatan positif, penskalaan vertikal dapat meregang cukup jauh dalam beberapa kasus. Sejauh yang saya tahu, SO berlari pada satu server untuk beberapa waktu. Saya tidak yakin bagaimana ini cocok dengan 10.000 pengguna Anda (saya kira itu akan tergantung pada sifat apa yang mereka lakukan di sistem Anda), tetapi ini memberi Anda gambaran tentang apa yang dapat dilakukan (sebenarnya, ada jauh contoh yang lebih mengesankan, ini hanya menjadi populer yang mudah dimengerti orang).
EDIT 2: Untuk mengklarifikasi dan mengomentari beberapa hal yang diangkat di tempat lain:
- Re: Konsistensi atom - Konsistensi ACID mungkin menjadi persyaratan sistem. Di atas tidak benar-benar membantah hal itu, dan Anda harus menyadari bahwa konsistensi ACID tidak mengharuskan Anda untuk menjalankan semua logika bisnis Anda di dalam DB. Dengan memindahkan kode yang tidak perlu ada di dalam DB, Anda membatasi untuk berjalan di lingkungan fisik sisa DB - itu bersaing untuk sumber daya perangkat keras yang sama dengan bagian manajemen data aktual dari DB Anda. Adapun hanya mengubah kode ke server DB lain (tetapi bukan data aktual) - tentu saja, ini mungkin terjadi , tetapi apa sebenarnya yang Anda peroleh di sini, selain dari biaya lisensi tambahan dalam banyak kasus? Simpan hal-hal yang tidak perlu pada DB, dari DB.
- Re: SQL / C # kinerja - karena ini tampaknya menjadi topik yang menarik, mari kita tambahkan sedikit ke diskusi. Anda tentu dapat menjalankan kode asli / Java / C # di dalam DB, tetapi sejauh yang saya tahu, bukan itu yang sedang dibahas di sini - kami membandingkan penerapan kode aplikasi yang khas dalam sesuatu seperti T-SQL versus sesuatu seperti C #. Ada sejumlah masalah yang sulit dipecahkan dengan kode relasional di masa lalu - mis. Pertimbangkan masalah "login bersamaan maksimum", di mana Anda memiliki catatan yang menunjukkan login atau keluar, dan waktu, dan Anda perlu mencari tahu apa yang jumlah maksimum pengguna yang masuk pada suatu waktu adalah. Solusi paling sederhana yang mungkin adalah untuk beralih melalui catatan dan terus menambah / mengurangi penghitung saat Anda menemukan login / logout, dan melacak maksimum nilai ini.mungkin, Saya tidak tahu), yang terbaik yang dapat Anda lakukan adalah CURSOR (solusi relasional murni semuanya pada urutan kompleksitas yang berbeda, dan mencoba menyelesaikannya menggunakan perulangan sementara menghasilkan kinerja yang lebih buruk). Dalam hal ini, ya, solusi C # sebenarnya lebih cepat dari apa yang dapat Anda capai di T-SQL, titik. Itu mungkin tampak tidak masuk akal, tetapi masalah ini dapat dengan mudah memanifestasikan dirinya dalam sistem keuangan, jika Anda bekerja dengan baris yang mewakili perubahan relatif, dan perlu menghitung agregasi berjendela tentang hal itu. Doa proc tersimpan juga cenderung lebih mahal - gunakan SP sepele satu juta kali dan lihat bagaimana membandingkannya dengan memanggil fungsi C #. Saya mengisyaratkan beberapa contoh lain di atas - saya belum menemukan orang yang mengimplementasikan tabel hash yang tepat di T-SQL (yang sebenarnya memberikan beberapa manfaat), sementara itu cukup mudah dilakukan di C #. Sekali lagi, ada hal-hal yang membuat DBs luar biasa, dan hal-hal yang mereka tidak begitu mengagumkan. Sama seperti saya tidak ingin melakukan GABUNGAN, SUM dan GROUP BYs dalam C #, saya tidak ingin menulis apa pun terutama CPU intensif di T-SQL.