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


33

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?


1
Bagaimana Anda mendefinisikan aplikasi: build terpisah, pengembang berbeda?
JeffO

Berbagi basis data mengubah seluruh basis data menjadi API publik yang besar dan berantakan. Dan itu kehilangan semua abstraksi yang mungkin Anda buat di aplikasi pertama.
Patrick

Apakah kinerja masalah? Dengan cukup catatan yang akan mencegah satu dari satu basis data tunggal. Ruang murah.
Rig

Jawaban:


41

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.


Ketika menggunakan layanan untuk shared db sesuai jawaban @ Saeed, bukankah saya masih memiliki keprihatinan dengan beberapa aplikasi yang tidak memiliki kebutuhan yang berbeda dan memerlukan berbagai indeks pada database?
Laz

2
@ Laz: Mungkin, tergantung pada kasus penggunaan dan persyaratan.
Falcon

2
Salah satu dasar dari desain database relasional adalah tidak memiliki data dupata. Memiliki basis data berbeda yang berisi tumpang tindih dari data yang sama hanya meminta masalah.
Pieter B

Pieter B: Saya berasumsi Anda belum pernah bekerja di lingkungan perusahaan, seperti untuk perusahaan besar. Memiliki satu basis data dengan berbagai aplikasi dan tim pengembangan yang berbeda hanya meminta masalah dan pada akhirnya dapat membuat pengembangan menjadi tertahan. Yang mengatakan, tidak pernah ada pilihan hitam dan putih imho.
Falcon

@PieterB: beberapa aplikasi membaca dan menulis data yang sama adalah indikasi yang baik bahwa Anda harus memperhitungkan lapisan layanan yang dapat digunakan oleh semua aplikasi untuk membuat permintaan. Di sisi lain, jika mereka cukup berbeda sehingga Anda tidak dapat memfaktorkan layanan umum, maka mereka cukup berbeda untuk memerlukan tabel / database terpisah.
Dan Lyons

23

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.


3
+1 untuk pemisahan logis dan menyarankan arsitektur yang bersih. SOA membuat hal-hal seperti itu menjadi sangat mudah
Falcon

Pasti memberi +1 untuk organisasi yang logis. Biarkan data dikelompokkan untuk mengoptimalkan keseimbangan kopling dan kohesi dan kemudian aplikasi dapat masuk ke dalam basis data apa pun yang mereka butuhkan untuk melakukan pekerjaan mereka.
Joel Brown

9

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.


3

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.


+1: Cukup mudah untuk memetakan banyak aplikasi ke satu basis data.
kevin cline

0

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.