SQL Server - pisahkan database untuk laporan?


19

Di SQL Server kami, kami memiliki database untuk masing-masing aplikasi web kami. Untuk laporan, kami menggunakan Layanan Pelaporan dan semua data laporan (termasuk parameter laporan) berasal dari prosedur tersimpan.

Prosedur yang tersimpan berada di database yang sama dengan data dalam laporan. Jadi, misalnya, procs yang melayani laporan Stock ada di database Stock. Beberapa laporan menunjukkan informasi dari lebih dari satu database dan kemudian proc akan berada di salah satu dari database sumber tersebut. Parameter laporan mendapatkan data mereka dari procs dalam database Perusahaan yang memiliki data seperti toko, karyawan, dll.

Ini berarti bahwa semua laporan memiliki setidaknya koneksi ke database Enterprise dan koneksi lain ke database lain - dan kadang-kadang lebih dari itu.

Pertanyaan saya adalah: apakah ada manfaat memindahkan procs pelaporan ke database "Laporan" yang terpisah . Saya tahu manfaat memindahkan laporan ke server lain dan saya tidak membicarakannya - ini akan berada di server yang sama.

Hal-hal yang mungkin memengaruhi ini adalah:

  • Apakah memiliki lebih dari satu koneksi database untuk suatu laporan, memengaruhi kecepatan laporan?
  • Apakah memiliki proc pelaporan dalam database terpisah dari data, mencegah kita menggunakan tampilan yang diindeks?
  • Sudahkah Anda merasa lebih mudah / lebih sulit mengelola laporan di basis data terpisah?

Tolong beritahu saya bagaimana menurut anda.


Pertanyaan saya adalah: Ketika Anda memindahkan RS dan / atau DW ke server lain apakah Anda memiliki Mesin Database yang ada di server baru ini? atau Anda menggunakan mesin database asli? - Jadi, apakah Anda harus memiliki mesin basis data terpisah untuk semua server SQL? Terima kasih, - Dom

Ya, kami memiliki mesin basis data terpisah di setiap server: server db & server DW. Sejak mengajukan pertanyaan, kami tetap menggunakan desain asli untuk menyimpan laporan dalam database yang sama (dan karenanya server yang sama) sebagai sumber data. Kami juga memindahkan data ke server data warehouse di mana pengguna mengaksesnya melalui kubus Layanan Analisis SQL Server.

Jawaban:


17

Jawabannya adalah: ya, ada manfaatnya melakukannya. Laporan tentang basis data operasional akan menggunakan banyak sumber daya dan akan mengganggu kinerja sistem operasional. Ingat bahwa kinerja basis data tunduk pada kendala mekanis (disk head bergerak bolak-balik dan latensi rotasi saat kami menunggu sektor yang tepat untuk membuat tampilan di bawah kepala). Anda memiliki dua opsi luas untuk strategi pelaporan:

  1. Gandakan database Anda ke server lain dan pindahkan sprocs pelaporan ke dalamnya. Laporan dijalankan dari server yang direplikasi. Ini adalah upaya yang paling sedikit dan dapat menggunakan kembali laporan dan prosedur tersimpan Anda yang ada.
  2. Bangun Gudang Data yang menggabungkan data dari sistem produksi Anda dan mengubahnya menjadi bentuk yang jauh lebih ramah untuk pelaporan . Jika Anda memiliki banyak pelaporan statistik ad-hoc yang dapat dilakukan dengan dapat diterima dari snapshot pada 'penutupan bisnis kemarin', gudang data mungkin merupakan pendekatan yang lebih baik.

Membangun gudang data dan memanfaatkan teknologi seperti OLAP di mana masuk akal meningkatkan pilihan Anda untuk menyediakan pelaporan yang cepat dan andal dengan dampak sesedikit mungkin pada sistem pemrosesan transaksi.

2

Saya pikir itu sangat tergantung pada jenis SP yang Anda jalankan. Jika mereka berat dan dapat mempengaruhi hal-hal lain yang berjalan di server database saya akan memindahkannya. Kalau tidak, saya akan mencoba dan tetap dekat dengan database yang sebenarnya mereka laporkan, jika merasa lebih mudah untuk mempertahankan dan melacak. Hanya memiliki laporan yang dekat dengan database aktual juga dapat mempengaruhi kinerja tetapi jika Anda menggunakan pengaturan standar dan tidak memindahkan data dalam jumlah besar, itu akan menjadi perbedaan kecil.

Saya juga menemukan artikel ini bermanfaat.


1

Saya merekomendasikan untuk tidak memindahkan prosedur tersimpan ke database lain karena beberapa alasan. Dari perspektif pengembangan Anda harus mereproduksi dua database setiap kali Anda ingin membuat perubahan. Sebagai konsekuensinya Anda sekarang akan bagaimana menyinkronkan skema dari database "data" dan prosedur yang tersimpan dari yang kedua dengan versi produksi. Berkenaan dengan pemulihan bencana dan cadangan / pemulihan, Anda sekarang harus mempedulikan diri Anda dengan pemulihan 2 database hanya untuk mendapatkan dan menjalankan sistem Anda.

Saat menguji Anda juga telah menambahkan kompleksitas. Anda akan memiliki lebih banyak poin kegagalan sehubungan dengan izin, versi, dll. Sekarang jika Anda memiliki lebih dari 1 orang yang bekerja pada inisiatif yang berbeda pada basis data, Anda memiliki lebih banyak waktu untuk mengoordinasikan upaya. Sekarang bayangkan jam 3 pagi, sistem mati dan Anda harus mencari izin di semua basis data, dan harus memastikan bahwa tidak ada yang meninggalkan fungsi atau prosedur pada basis data yang salah selama pengembangan.


1

Saya sarankan Anda menggunakan dua database.

Mendapatkan laporan dari database 'langsung' menyebabkan masalah kinerja.

Juga, karena basis data pelaporan terutama untuk pencarian, Anda dapat menyesuaikan indeks di sini untuk kinerja yang lebih baik. (Basis data langsung akan memiliki sisipan yang akan terpengaruh secara merugikan oleh indeks tertentu)


0

Pendekatan lain adalah memindahkan tabel pelaporan ke skema yang terpisah dan memisahkan grup file. File dalam melaporkan kelompok file dapat dipindahkan dari hard disk data. Lapisan ini jauh lebih mudah untuk administrasi, pengembangan di masa depan dan manajemen akses.

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.