Anda akan berharap telah menggunakan database terpisah:
- Jika Anda ingin memberikan izin ke database itu sendiri kepada klien atau pengguna super.
- Jika Anda ingin memulihkan hanya satu database klien tanpa memengaruhi data klien lainnya.
- Jika ada masalah peraturan yang mengatur data dan pelanggaran data Anda, dan Anda terlambat menemukan bahwa peraturan ini hanya dapat dipenuhi dengan memiliki database terpisah. (Pembaruan:sedikit lebih dari 4 tahun setelah penulisan jawaban ini, GDPR mulai berlaku)
- Jika Anda ingin dengan mudah memindahkan data pelanggan Anda ke beberapa server database atau memperbesar skala, atau memindahkan pelanggan yang lebih besar/lebih penting ke perangkat keras yang berbeda. Di belahan dunia yang berbeda.
- Jika Anda ingin mengarsipkan dan menonaktifkan data pelanggan lama dengan mudah.
- Jika pelanggan Anda peduli dengan data mereka yang disimpan dalam silo, dan mereka mengetahui bahwa Anda melakukan sebaliknya.
- Jika data Anda dipanggil dan sulit untuk mengekstrak hanya satu data pelanggan, atau panggilan pengadilan terlalu luas dan Anda harus membuat seluruh database, bukan hanya data untuk satu klien.
- Ketika Anda lupa untuk menjaga kewaspadaan dan hanya satu kueri yang lolos yang tidak menyertakan
AND CustomerID = @CustomerID. Petunjuk:gunakan alat izin skrip, atau skema, atau bungkus semua tabel dengan tampilan yang menyertakanWHERE CustomerID = SomeUserReturningFunction(), atau beberapa kombinasinya. - Saat Anda mendapatkan izin yang salah di tingkat aplikasi dan data pelanggan terekspos ke pelanggan yang salah.
- Bila Anda ingin memiliki tingkat perlindungan pencadangan dan pemulihan yang berbeda untuk klien yang berbeda.
- Begitu Anda menyadari bahwa membangun infrastruktur untuk membuat, menyediakan, mengonfigurasi, menyebarkan, dan sebaliknya meningkatkan/menurunkan basis data baru layak untuk investasi karena memaksa Anda untuk menjadi ahli dalam hal itu.
- Bila Anda tidak mengizinkan kemungkinan beberapa kelas orang membutuhkan akses ke beberapa data pelanggan, dan Anda memerlukan lapisan abstraksi di atas
CustomerkarenaWHERE CustomerID = @CustomerIDtidak akan dipotong sekarang. - Saat peretas menargetkan situs atau sistem Anda, dan Anda memudahkan mereka untuk mendapatkan semua data semua pelanggan Anda sekaligus setelah mendapatkan kredensial admin hanya dalam satu basis data.
- Bila pencadangan basis data Anda membutuhkan waktu 5 jam untuk dijalankan dan kemudian gagal.
- Bila Anda harus mendapatkan DBMS edisi Enterprise agar Anda dapat membuat cadangan terkompresi sehingga penyalinan file cadangan melalui jaringan membutuhkan waktu kurang dari 5 jam lebih .
- Saat Anda harus memulihkan seluruh database setiap hari ke server pengujian yang membutuhkan waktu 5 jam, dan menjalankan skrip validasi yang membutuhkan waktu 2 jam untuk diselesaikan.
- Bila hanya beberapa pelanggan Anda yang membutuhkan replikasi dan Anda harus menerapkannya ke semua pelanggan Anda, bukan hanya beberapa pelanggan tersebut.
- Saat Anda ingin menghadapi pelanggan pemerintah dan mengetahui bahwa mereka mengharuskan Anda menggunakan server dan database terpisah, namun ekosistem Anda dibangun di sekitar satu server dan database dan itu terlalu sulit atau akan terlalu lama untuk diubah .
Anda akan senang menggunakan database terpisah:
- Saat peluncuran percontohan ke satu pelanggan benar-benar meledak dan 999 pelanggan lainnya sama sekali tidak terpengaruh. Dan Anda dapat memulihkan dari cadangan untuk memperbaiki masalah.
- Bila salah satu cadangan database Anda gagal dan Anda dapat memperbaikinya hanya dalam 25 menit daripada memulai seluruh proses 10 jam lagi.
Anda akan berharap telah menggunakan satu database:
- Saat Anda menemukan bug yang memengaruhi 1000 klien dan sulit menerapkan perbaikan ke 1000 database.
- Bila Anda mendapatkan izin yang salah di tingkat basis data dan data pelanggan terekspos ke pelanggan yang salah.
- Bila Anda tidak mengizinkan kemungkinan beberapa kelas orang yang memerlukan akses ke subset semua database (mungkin dua pelanggan bergabung).
- Saat Anda tidak berpikir betapa sulitnya menggabungkan dua database data yang berbeda.
- Saat Anda menggabungkan dua database data yang berbeda dan menyadari salah satunya, dan Anda tidak berencana untuk memulihkan dari skenario ini.
- Ketika Anda mencoba untuk tumbuh melewati 32.767 pelanggan/database pada satu server dan mengetahui bahwa ini adalah jumlah maksimum di SQL Server 2012.
- Saat Anda menyadari bahwa mengelola 1.000+ database adalah mimpi buruk yang lebih besar dari yang pernah Anda bayangkan.
- Ketika Anda menyadari bahwa Anda tidak dapat memasukkan pelanggan baru hanya dengan menambahkan beberapa data dalam tabel, dan Anda harus menjalankan banyak skrip menakutkan dan rumit untuk membuat, mengisi, dan menetapkan izin pada database baru.
- Bila Anda harus menjalankan 1000 cadangan basis data setiap hari, pastikan semuanya berhasil, salin melalui jaringan, pulihkan semuanya ke basis data pengujian, dan jalankan skrip validasi pada masing-masing cadangan, laporkan kegagalan apa pun dengan cara yang akan dijamin untuk dilihat, dan yang mudah dan cepat ditindaklanjuti. Dan kemudian 150 di antaranya gagal di berbagai tempat dan harus diperbaiki satu per satu.
- Saat Anda mengetahuinya, Anda harus menyiapkan replikasi untuk 1000 database.
Hanya karena saya mencantumkan lebih banyak alasan bukan berarti itu lebih baik.
Beberapa pembaca mungkin mendapatkan nilai dari MSDN:Multi -Arsitektur Data Penyewa . Atau mungkin Pola Desain Aplikasi Tenancy SaaS . Atau bahkan Mengembangkan Multi-tenant Aplikasi untuk Cloud, Edisi ke-3
