Haruskah saya menggunakan satu database per aplikasi atau berbagi satu database di antara beberapa aplikasi [ditutup]

Saya memiliki beberapa aplikasi, beberapa menggunakan data dari sumber yang sama. Apakah ini praktik terbaik (atau apa pro / kontra) untuk:

• meninggalkan data dalam database bersama oleh banyak aplikasi

  1. menghemat ruang karena hanya satu database yang dibutuhkan
  2. mempersulit pengindeksan karena aplikasi yang berbeda memiliki kebutuhan kueri yang berbeda

• impor data setiap hari ke dalam basis data per-aplikasi

  1. menggunakan lebih banyak ruang karena data duplikat ada dalam database per-aplikasi
  2. pengindeksan lebih mudah karena setiap aplikasi dapat fokus pada kebutuhan masing-masing

Saya mungkin telah mengabaikan kelebihan / kekurangan lain, harap sebutkan jika ada, juga bagaimana hal ini dilakukan di tempat kerja Anda?

Space murah hari ini, jadi saya sarankan untuk menggunakan satu database per aplikasi.

Berbagi satu database untuk beberapa aplikasi memiliki beberapa kelemahan serius :

• Semakin banyak aplikasi menggunakan database yang sama, semakin besar kemungkinan Anda menekan hambatan kinerja dan Anda tidak dapat dengan mudah menskalakan beban seperti yang diinginkan . Database SQL tidak benar-benar skala. Anda dapat membeli mesin yang lebih besar tetapi tidak memiliki skala yang baik dalam kelompok!

• Biaya pemeliharaan dan pengembangan dapat meningkat : Pengembangan lebih sulit jika aplikasi perlu menggunakan struktur basis data yang tidak cocok untuk tugas yang dihadapi tetapi harus digunakan karena sudah ada. Kemungkinan juga penyesuaian satu aplikasi akan memiliki efek samping pada aplikasi lain ("mengapa ada pemicu yang tidak perlu seperti itu ??!" / "Kami tidak membutuhkan data itu lagi!"). Sudah sulit dengan satu database untuk satu aplikasi, ketika pengembang tidak / tidak bisa mengetahui semua kasus penggunaan.

• Administrasi menjadi lebih sulit: Objek mana yang menjadi milik aplikasi yang mana? Kekacauan meningkat. Di mana saya harus mencari data saya? Pengguna mana yang diizinkan berinteraksi dengan objek mana? Apa yang bisa saya berikan kepada siapa?

• Peningkatan: Anda memerlukan versi yang merupakan penyebut umum terendah untuk semua aplikasi yang menggunakannya. Itu berarti bahwa aplikasi tertentu tidak akan dapat menggunakan fitur canggih. Anda harus tetap menggunakan versi yang lebih lama. Ini juga sedikit meningkatkan biaya pengembangan.

• Concurrency: Dapatkah Anda benar-benar yakin bahwa tidak ada dependensi kronologis antara proses? Bagaimana jika satu aplikasi memodifikasi data yang sudah usang atau seharusnya diubah oleh aplikasi lain terlebih dahulu? Bagaimana dengan aplikasi yang berbeda yang bekerja pada tabel yang sama secara bersamaan?

Dibandingkan dengan itu, impor data / proses ETL hampir selalu sangat mudah dan sederhana. Muat data sesering yang Anda perlukan, ruang murah. Anda dapat menjelaskan skalabilitas untuk setiap aplikasi secara mandiri, menyesuaikan dan mengubah struktur sesuai kebutuhan Anda dan tidak akan ada masalah konkurensi. Efek samping dapat ditelusuri lebih mudah juga.

Sunting: Saya ingin menunjukkan, bahwa, seperti yang disebutkan @Saeed, jika Anda dapat merangkum manipulasi data dalam layanan yang umumnya tersedia, maka lebih mudah untuk berbagi satu database dengan beberapa aplikasi. Selama Anda tidak memerlukan akses mentah, itu adalah pendekatan yang sangat bagus.

Saya pernah mengalami situasi yang sama. Masalah saya adalah membangun 3 aplikasi, satu untuk manajemen inventaris, satu untuk manajemen pengadaan, dan satu untuk mengelola pengguna, yaitu karyawan. Rekomendasi saya adalah tidak memecah database secara fisik per aplikasi, atau bergabung secara fisik per aplikasi. Sebaliknya, pemisahan logis IMHO berfungsi lebih baik.

Misalnya, ketiga aplikasi yang diperlukan untuk bekerja dengan informasi karyawan. Baik sistem persediaan maupun pengadaan menggunakan informasi barang dan barang inventaris yang sama.

Saya membuat database bersama, di mana saya menyimpan informasi pengguna dan barang. Lalu saya membangun lapisan layanan di atasnya dan saya menggunakan layanan itu di aplikasi lain. Untuk menunjukkan daftar semua karyawan yang sekarang di perusahaan misalnya, saya hanya perlu memanggil metode dari layanan seperti GetOnWorkEmployees().

Saya juga membuat UI umum untuk berinteraksi dengan pengguna dan barang yang merupakan aplikasi web tersendiri.

Jadi, menambahkan apa yang telah ditunjukkan oleh @Falcon, saya pikir Anda dapat mengambil manfaat dari memusatkan fungsi umum di antara aplikasi dalam satu basis data.

Jika aplikasi ini dimaksudkan untuk bekerja dari data yang sama - misalnya, daftar produk dan pelanggan yang sama - maka satukan database. Anda tidak mendapatkan apa-apa dengan memisahkan basis data. Itu murni masalah 'manusia' - ke server itu hanya byte pada disk. Tidak peduli jika 1 atau 100 databasenya. Tetapi jika Anda membaginya, maka Anda harus berurusan dengan sinkronisasi data. Masalah pengindeksan yang Anda tampilkan bukan masalah nyata - Anda akan menghabiskan jumlah waktu prosesor yang sama untuk mempertahankan indeks jika db's terpecah.

Jika kinerja mulai menjadi masalah, gandakan db ke beberapa server untuk menyeimbangkan semuanya.

Mungkin bermanfaat atau tidak sebanding dengan situasi Anda, tetapi menjaga integritas data lebih mudah dengan satu basis data. Setidaknya dalam MS SQL Server, Anda tidak bisa kunci asing dari satu database ke database yang berbeda. Anda dapat mensimulasikan perilaku kunci asing dengan pemicu, tetapi tidak terlalu elegan.

Selain itu, membuat salinan data lokal bisa berbahaya saat penulisan turut dilakukan. Jika AppA dan AppB memiliki salinan dari beberapa data bersama dan AppA memperbaruinya, AppB masih akan memiliki data yang lama. Atau, Anda harus mengatur pemicu agar data tetap sinkron.

Suatu kali saya memiliki beberapa situs web yang semakin populer dari waktu ke waktu. Mereka menggunakan basis data terpisah, sebagian besar karena penyedia hosting masing-masing hanya mengizinkan ruang penyimpanan 1Gb. Tapi! Segera setelah saya merilis layanan yang mencakup semua situs web ini, saya mulai harus melakukan transaksi di antara situs-situs web ini, dan cara paling mudah untuk melakukan ini adalah dengan memindahkan semuanya ke dalam satu basis data besar.

Jadi saya mengoptimalkan struktur basis data dan menekan bagian-bagian yang relevan ke basis data pusat ini, tetapi mengabaikan yang lainnya.

Pendapat saya entah bagaimana terkait dengan paradigma OOP. Data serupa harus disimpan bersama, jadi jika Anda membangun aplikasi yang berbeda, Anda harus menggunakan database yang berbeda untuk mereka.

Dalam kasus di atas menggunakan common db tidak dapat dihindari, tetapi ingat bahwa saya juga menyimpan beberapa tabel dalam db yang terpisah, yang bukan bagian dari permintaan umum.

Selain itu, jika Anda memisahkan mereka, mereka akan lebih mudah untuk membuat cadangan, akan ada lebih sedikit kesempatan untuk kehilangan data. Jika ada yang tidak beres dan aplikasi saling mengganggu, basis data akan kacau, dan Anda pada dasarnya tidak ingin mengekspos aplikasi Anda terhadap bahaya ini.

Secara keseluruhan, Anda bisa memelihara database umum untuk pertanyaan umum, tetapi juga menyimpan satu untuk setiap aplikasi Anda.

Bisakah Anda menguraikan lebih lanjut tentang arsitektur aplikasi Anda?

Jika database Anda berfungsi hanya sebagai repositori data tanpa logika aplikasi seperti pemicu atau kode paket bisnis, akan lebih baik untuk memiliki database tunggal dan merangkum fungsionalitas tingkat bisnis ke layanan yang menggunakan database untuk semua tindakan mereka. Jika Anda memiliki pemicu atau kode dalam skema basis data, Anda akan mendapat masalah besar dengan menggunakan satu basis data yang dapat menyulitkan dalam banyak kasus.