Single V / s Multiple Database

Saya telah membangun aplikasi web ini (php & mysql) yang menyimpan informasi untuk berbagai organisasi (sekitar 20 klien saat ini).

Skenario saat ini menyimpan informasi terkait klien dalam basis data individual, jadi ada 20 basis data klien dan 1 basis data master.

Salah satu keuntungan utama di sini adalah karena setiap klien db diisolasi, penomoran artefak klien (laporan, audit) dll diurutkan; memberi klien kami perasaan aman.

Setiap DB memiliki sekitar 15 tabel, dan paling banyak baris dalam tabel adalah sekitar 2000. Ini diharapkan paling banyak mencapai 5.000 catatan, paling banyak.

Mengelola perubahan db-level tunggal berarti mengubah 20 basis data, tetapi jika saya perlu melakukan perubahan seperti itu, saya menggunakan skrip yang melakukan ini dalam panggilan fungsi tunggal.

Kami berada pada pengaturan hosting bersama, dan ISP kami menyediakan kami dengan no terbatas. dari basis data; dan itulah yang membuat saya berpikir dalam hal memusatkan basis data; sehingga SEMUA data klien dapat disimpan dalam database master.

Tentu saja, beberapa masalah penting yang muncul adalah:

Sebuah. Mempertahankan urutan artefak, (ini dapat diatasi dengan membuat kunci referensi tambahan) b. Kecepatan dan kinerja (dalam hal ini saya dapat membuat indeks untuk mempercepat) c. Keamanan: Ini akan dikelola karena setiap kueri yang mengambil info klien. juga akan melacak client_id mereka

Di masa depan, kita mungkin perlu mempertimbangkan membandingkan dataset dari satu organisasi dengan organisasi lain, tapi saya percaya itu dapat dicapai pada db terpusat juga. Saya agak cenderung (untuk alasan kinerja dan pemeliharaan) untuk pindah ke database terpusat.

Apakah Anda pikir pindah ke database terpusat lebih masuk akal daripada tetap seperti kita (pada database individu)?

Terima kasih atas saranmu.

Ada risiko bawaan dan penghargaan untuk kedua sistem. Saya bekerja untuk sebuah perusahaan keuangan yang mendukung sekitar 40 klien (bank nasional) pada 1 basis data. Kami kemudian membeli perusahaan lain yang menjual perangkat lunak serupa dan telah menggunakan 1 basis data per klien. Akhirnya, perusahaan bangkrut dan kami memang harus mengekspor semua data pengguna. Inilah yang saya dan orang-orang tempat saya bekerja:

Pro dari Single DB:

1. Pembaruan perangkat lunak dan perbaikan bug lebih mudah.
2. Mudah mengelola dan melaporkan semua data klien.
3. Memperbarui data menjadi lebih mudah.
4. Mudah untuk membuat fungsionalitas modular yang diinginkan 1 klien, matikan jika untuk klien lain, dan kemudian matikan ketika mereka menginginkannya di masa depan.

Con's of Single DB:

1. Integritas data - Kami memiliki 2 atau 3 kasus di mana 1 pengguna bank melihat data bank lain. Ini adalah mimpi buruk. Terutama karena pengguna situs bukan hanya karyawan bank tetapi juga pelanggan yang memegang rekening bank! Sejauh ini, ini adalah masalah terbesar dengan 1 basis data
2. Mengekspor data klien -Ketika kami harus melakukan ini biasanya itu bukan masalah besar. Anda berakhir dengan 1 tabel yang memiliki semua klien di dalamnya dan Anda kunci dari tabel itu untuk mendapatkan data spesifik klien Anda.

Pro of Multiple DBs:

1. Tidak ada kekhawatiran kontaminasi data lintas klien atau pelanggaran
2. Mengekspor data klien sangat mudah.

Con's of Multiple DBs:

1. Pembaruan dan perbaikan bug - Ini adalah mimpi buruk yang nyata. Ketika Anda memiliki 20 klien pada 20 basis data yang berbeda, Anda dengan cepat mengalami kasus di mana 1 klien ingin bug diperbaiki dan yang lain berpikir bug tersebut adalah fitur atau tidak ingin mengambil risiko pembaruan. Selanjutnya, Anda akan memiliki contoh di mana 1 klien menginginkan peningkatan permainan yang berubah tetapi klien lain tidak. Ketika ini terjadi, basis data Anda akan mulai menyimpang. Tiba-tiba Anda harus memperbarui klien 1-15 dengan 1 skrip 16-19 dengan yang lain, dan 20 dengan yang ketiga. Kami melihat ini menjadi masalah sehingga perbaikan bug akan memakan waktu 15 hingga 20 kali lebih lama untuk perusahaan yang kami beli daripada bagi kami karena mereka harus menjalankan semua tes untuk setiap klien dan menangani kode khusus masing-masing klien. Secara efektif, mereka membutuhkan orang dukungan baru untuk setiap klien baru,
2. Manajemen DB - Ketika Anda mendapatkan sejumlah besar klien yang mengelola semua basis data menjadi masalah nyata. Anda pasti membutuhkan lebih banyak waktu DBA untuk mengelolanya.

Pada akhirnya rekomendasi saya setelah melihat dan melakukan keduanya adalah memiliki "disiplin"! Saya pikir pilihan multi-db sedikit lebih baik karena melindungi Anda tetapi Anda tidak dapat membiarkan klien Anda membuat pilihan yang menyebabkan Anda menambahkan fungsionalitas hanya kepada mereka atau Anda akan menempatkan diri Anda pada jalan menuju kegagalan.

Saya akan memiliki database terpisah untuk klien terpisah. Klien mungkin menuntut ini karena alasan keamanan - yaitu hanya situs mereka yang memiliki akses ke data mereka. Ini juga berarti bahwa jika klien ingin memindahkan data mereka maka itu akan jauh lebih mudah untuk dikelola.

Ini juga berarti bahwa jika ada masalah dengan database satu klien, itu tidak mempengaruhi yang lain.

Jika Anda ingin membandingkan data antara klien maka Anda harus melakukannya secara terpisah.

Jika Anda kehabisan database yang dapat Anda miliki maka mungkin Anda harus mempertimbangkan untuk mengubah penyedia host Anda.

Satu-satunya alasan saya tidak akan memiliki database individual untuk setiap klien adalah jika Anda akan memiliki 100-an atau 1000-an klien / database. Ini bisa menjadi sangat berbulu untuk dikelola termasuk membuat perubahan basis data atau melakukan sesuatu di semua basis data. Tindakan yang terjadi di sejumlah besar banyak basis data juga bisa lambat karena Anda perlu membuka (dan karenanya menutup) begitu banyak tabel.

Tapi selain dari kasus ini, saya pikir banyak basis data lebih baik.

Satu keuntungan, yang mungkin tidak penting tetapi dapat bermanfaat, adalah bahwa setiap klien mendapatkan ID berurutan mereka sendiri (bukannya mungkin melewatkan sekelompok karena klien lain menambahkan catatan).

Selain itu, banyak basis data memungkinkan sub tabel (seperti jenis telepon) mudah disesuaikan untuk setiap klien tanpa perlu ID catatan induk dalam tabel ini juga.

Pertama urutan artefak. Saya berasumsi Anda menggunakan kunci primer integer untuk memberikan ini. Sungguh, Anda harus memiliki kolom "nomor artefak" yang terpisah. PK harus PK dan bukan yang lain. Orang-orang berbicara tentang "kunci alami" dan sejenisnya dan saya merasa ngeri. Setiap kali Anda mengandalkan PK untuk menjadi lebih dari pengenal, ia kembali menggigit Anda. Jika Anda ingin mengetahui urutan sesuatu, simpan tanggal atau nomor urut.

Saya pikir dalam manajemen konfigurasi kasus Anda akan mengarahkan Anda ke satu database. Lihatlah berapa biaya yang harus Anda keluarkan untuk memelihara dan meningkatkan basis data. Berapa biaya yang terkait dengan setiap rilis perangkat lunak? Juga pikirkan biaya ketika Anda mendapatkan pelanggan baru dan harus membuat DB dan mengkonfigurasi aplikasi untuk itu. Apa pun dapat diotomatisasi, pertanyaannya adalah, apakah itu akan sia-sia ketika Anda memiliki 100 database?

Di ujung jalan, lebih mudah untuk skala (partisi, perangkat keras, sharding dll) satu database daripada melakukan hal yang sama untuk 100 database.

Saya pikir poster lain telah membuat beberapa poin yang sangat bagus jadi saya tidak akan membahasnya.

Untuk menambah pro / con terdaftar hingga sekarang:

Pro tentang banyak basis data:

1. Masalah penguncian dihindari; kami punya database di mana klien dapat memicu perubahan-DDL pada beberapa tabel. Untuk tabel yang lebih besar (> catatan 2m) ini mengunci tabel untuk waktu yang cukup lama. Satu-satunya orang yang dirugikan adalah pengguna mereka sendiri, jadi ini semacam diterima.

2. Fleksibilitas - beberapa klien memiliki keinginan spesifik terkait data yang ingin mereka simpan; multi-database memungkinkan kami fleksibilitas untuk mengubah database mereka secara khusus, tanpa harus mengacaukan model data untuk klien lain.

Cons:

1. Kontra utama: Bergabung di meja lain jauh lebih rumit. Kami memiliki database Utama yang berisi sebagian besar meta-data. Pengguna basis data khusus klien tidak memiliki akses ke basis data ini, jadi semua gabungan antara tabel dalam basis data itu dan basis spesifik klien ditangani dalam aplikasi alih-alih dalam basis data. Anda dapat menyelesaikan ini dengan memberikan pengguna khusus klien akses ke database utama, tetapi kemudian aplikasi dapat / mungkin membocorkan informasi lagi.

Semoga beruntung dalam memilih!

Saya tahu Anda sudah memilih jawaban, tetapi sepertinya ada solusi lain yang tidak disarankan:

Pindahkan semuanya ke satu database, tetapi buat tabel untuk setiap pelanggan, menggunakan awalan, seperti ini:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Ini jenis yang terbaik dari kedua dunia.

• Sangat mudah untuk bermigrasi dari pengaturan Anda saat ini ke pengaturan baru.
• Anda dapat membuat 1 pengguna per klien dan membatasi hak istimewanya pada tabel perusahaannya dan tidak ada yang lain
• Anda dapat membuat pengguna super dan dengan mudah mengumpulkan data jika Anda perlu melakukannya.
• Gunakan hanya satu database