Apakah sebaiknya menggunakan Sinonim untuk menghindari membuat tabel duplikat?

13

Kami memiliki 3 salinan dari database yang sama persis. Semua 3 database memiliki Userstabel, dan Pengguna akan selalu ada di semua 3 database dengan pengaturan yang sama persis. Kapan saja kami ingin menambah atau mengedit Pengguna, kami harus memperbarui 3 basis data.

Apakah lebih baik menghapus Userstabel dari basis data 2 dan 3 dan menggantinya dengan Synonymyang menunjuk ke basis data 1?

Inilah Pro / Kontra yang bisa saya pikirkan:

Pro

Perawatan yang Lebih Mudah. Dapat memperbarui Pengguna di satu lokasi, bukan 3
Id Pengguna akan cocok di antara basis data (Penting karena banyak aplikasi tambahan didasarkan pada UserId)

Cons

Jangan berpikir ini adalah prosedur standar, jadi mungkin membingungkan
Pengguna harus memiliki pengaturan yang identik antara database
(Dari jawaban gbn di bawah) Jika Database 1 pernah turun, Database 2 dan 3 juga tidak akan tersedia. Juga ada masalah potensial dari data yang tidak konsisten dalam hal pemulihan

Ini adalah opsi yang saya pertimbangkan untuk beberapa tabel berbeda yang berisi Pengaturan yang identik antara database, bukan hanya Userstabel. Saya menggunakan Pengguna dalam contoh karena mudah dimengerti.

sql-server database-design

— Rachel
sumber

3

Apakah lebih masuk akal untuk memiliki skrip untuk menyinkronkan / menggabungkan perbedaan di antara mereka? Saya pribadi tidak suka membuat 2 basis data bergantung pada yang ketiga karena sinonim seperti ini.

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner Sepertinya itu lebih banyak pekerjaan, dan sulit untuk menggabungkan perubahan ke bidang yang dibuat secara otomatis seperti kunci primer.

— Rachel

Itu tergantung pada seberapa mewah yang Anda inginkan. Jika Anda ingin berbagi perubahan di antara mereka, maka ya itu bisa menjadi rumit. Jika Anda ingin menetapkan satu sebagai Master, maka itu hanya masalah menimpa isi yang lain dengan konten Master.

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner Sayangnya aplikasi ini adalah sumber tertutup dan tidak ada yang menghentikan orang untuk menambahkan atau mengedit pengguna di Database apa pun. Saya harus melakukan perubahan dua arah karena setiap orang memiliki kemampuan untuk mengubah kata sandi mereka sendiri, dan hampir semua manajer memiliki akses ke manajemen pengguna untuk menambah / mengedit pengguna.

— Rachel

6

Mengapa Anda memiliki 3 database dengan pengguna yang sama?

Apa yang terjadi jika satu basis data turun sekarang?

Saya mengajukan pertanyaan ini karena Con dari database sumber pengguna turun mencegah penggunaan dua database lain mungkin tidak menjadi masalah besar seperti kedengarannya.

Selain itu, jika database turun sekarang, Anda akan memiliki masalah konsistensi jika pengguna dimodifikasi di dua DB lainnya selama periode itu. Saya tidak berpikir kita bisa memberikan saran terbaik tanpa lebih banyak konteks.

Saat ini saya akan membuat database keempat untuk pengguna, membuat perubahan hanya di sana, dan menyinkronkan di database lain. Anda sudah terdistribusi-dinormalisasi dengan mengubah dasarnya data yang sama di tiga tempat, dan mungkin sudah memiliki masalah konsistensi. Jika toleransi kesalahan penting maka skema ini masih memberikan itu sambil menyelesaikan masalah multiple entry.

Saya pikir memiliki basis data pengguna / pengaturan-keempat ini daripada menggunakan salah satu yang sudah ada adalah strategi yang baik karena menjadi lebih kecil kemungkinannya karena tidak terikat dengan sumber daya lain atau banyak digunakan. Saya mengerti sekarang bahwa Anda mengatakan Anda tidak dapat melakukan ini, tetapi saya tidak jelas mengapa. Apakah aplikasi pada basis data utama mendukung pengeditan pengguna secara langsung, atau apakah pengeditan pengguna merupakan fungsi yang sepenuhnya terpisah yang dapat diarahkan ke tempat lain?

Benar, dengan ide "tabel pengguna kanonik" ini - apakah Anda menggunakan sinonim atau menyinkronkan data - Anda tidak dapat memodifikasi pengguna selama DB pengguna yang tidak digunakan, tetapi itu tampaknya tidak masalah bagi saya. Perbaiki masalah dan angkat! Satu sumber, satu tempat untuk mengedit, satu hal untuk diperbaiki jika rusak. Dengan sinkronisasi, semua database lain memiliki salinan sementara yang dapat digunakan, tetapi tanpa pengeditan. Meminimalkan duplikasi data lintas sistem adalah tujuan yang hebat dan bermanfaat. Ini adalah masalah serius untuk memasukkan data yang sama di tiga tempat, jadi lakukan apa pun yang Anda bisa untuk menghilangkannya.

Untuk membahas lebih banyak komentar Anda, jika ID pengguna Anda berbeda di semua aplikasi Anda, maka Anda harus secara serius mempertimbangkan waktu henti yang direncanakan untuk dua database baru Anda untuk menyelaraskannya dengan yang utama (ajukan pertanyaan terpisah jika Anda memerlukan ide tentang cara mencapai ini, yang sulit tetapi tidak terlalu sulit).

Jika Anda menganalisis kebutuhan bisnis Anda dan menemukan bahwa basis data utama harus memiliki data pengguna yang tidak apa-apa, Anda masih menggunakannya sebagai kanonik, lalu pilih antara sinonim atau sinkronisasi untuk mengatasi bagaimana waktu tidak terencana memengaruhi semua basis data.

Satu Con tambahan untuk menggunakan sinonim adalah bahwa Anda tidak lagi dapat memiliki FK yang tepat untuk Pengguna di setiap database.

— ErikE
sumber

3

Ada "Con" yang hilang

Saat pengembalian, ada kemungkinan bahwa pengguna Anda tidak akan ada dalam database target (dari sinonim). Katakanlah itu rusak, dan Anda harus memulihkan dari cadangan.

Artinya, penggunaan sinonim akan mengasumsikan integritas referensial cross-database yang tidak dapat terjadi dalam kehidupan nyata.

Konsekuensi lain dari ini adalah userid yang tidak cocok ketika Anda mencoba untuk memulihkan dari ini. (dengan menambahkan pengguna setelah pemulihan). Namun, ini seharusnya tidak boleh diasumsikan karena integritas referensial cross-database yang saya sebutkan.

Jadi, jangan lakukan itu ...

Jawaban terkait pada dba.se: Kriteria keputusan kapan harus menggunakan skema non-dbo vs Database baru tentang "integritas referensial lintas-database" setelah dipulihkan

— gbn
sumber

Poin bagus tentang kemungkinan target tidak ada, meskipun saya masih mencoba mencari tahu mengapa tautan tersebut terkait dengan pertanyaan ini

— Rachel

1

@Rachel: tidak, tabel target bisa ada tetapi datanya mungkin lebih tua. Jadi, ketika Anda mengembalikan, Anda memiliki pengguna yang hilang ... Tautan ini tentang "integritas referensial lintas-basis data"

— gbn

2

Bergantung pada platform basis data Anda, opsi lain adalah menghapus tabel dalam basis data 2 dan 3 dan menggantinya dengan tampilan terwujud dari tabel dalam basis data 1.

Pro

Perawatan Lebih Mudah (Dari data)
Id yang cocok
Pemadaman tidak memengaruhi basis data lain (setidaknya sampai perubahan perlu dilakukan)
Basis data apa pun dapat digunakan untuk memulihkan tabel.

Cons

Data hanya mutakhir seperti jadwal penyegaran Anda.
Jika definisi tabel berubah tampilan terwujud mungkin perlu diubah juga.

Juga perhatikan bahwa tergantung pada frekuensi pencarian, frekuensi penyegaran, dan frekuensi perubahan data, ini mungkin atau mungkin tidak memuat lebih banyak daripada solusi sinonim.

Pembaruan: Komentar FrustratedWithFormsDesigner pada dasarnya adalah Tampilan Terwujud untuk platform yang tidak dapat melakukan pandangan terwujud. Dengan menggunakan skrip, tabel dapat disinkronkan secara berkala. Jika satu database ditetapkan sebagai master, maka semua skrip dapat membuat perubahan berdasarkan pada itu. Ini akan memiliki semua pro dan kontra dari pandangan terwujud; tidak bisa memanfaatkan fungsionalitas bawaan.

— Leigh Riffel
sumber

1

Anda tidak dapat mematerialisasi tampilan (tampilan indeks di sini) cross-db di SQL Server + mereka tidak perlu di-refresh: itu adalah "waktu nyata"

— gbn

@ gbn Posting saya ditulis sebelum tag SQL Server ditambahkan.

— Leigh Riffel

Saya menambahkan tag berdasarkan jawaban Anda :)

— Rachel

1

Saya akan membuat DB ke-4 yang menyimpan Info Pengguna yang dibagikan. Buat Synonymsatau Viewsdi masing-masing DBS lain yang menunjuk ke DB Pengguna.

Terakhir saya akan membuat tabel ekstensi (tabel dengan hubungan One-one dengan 'UserDB.Usertable') di masing-masing dari 3 dbs yang ada yang menyimpan data pengguna khusus untuk aplikasi itu.

Sunting: Berdasarkan komentar di bawah ini

Dalam hal ini, buat First db bertindak sebagai tabel pengguna Master. Synonymsdan tabel ekstensi di masing-masing Dbs Lainnya.

Catatan penting : Dengan pendekatan ini, Jika aplikasi pertama Anda turun, dua lainnya ditarik ke bawah dengan itu! Pastikan semua orang memahami kelemahan ini.

— Orang bodoh
sumber

Sayangnya itu bukan pilihan bagi saya. Ini akan menjadi pilihan saya jika saya merancang sesuatu dari awal, tetapi dalam hal ini saya bekerja dengan sistem yang sudah ada sebelumnya. Dalam kasus saya, kami memiliki Database 1 yang ada selama bertahun-tahun, dan baru-baru ini menambahkan Database 2 dan 3.

— Rachel

Mengapa bisa menghapus tabel dan mengarahkan Sinonim ke db pertama tetapi tidak ke yang baru?

Maaf, edit komentar saya sebelum saya melihat milik Anda. Database 1 telah ada selama bertahun-tahun dan diakses oleh banyak aplikasi eksternal. Saya tidak yakin kerusakan apa yang saya sebabkan dengan menghapus meja itu. Basis data 2 dan 3 lebih baru jadi saya pikir saya bisa menghapus tabel Users (dan tabel pengaturan lainnya) dan menggantinya dengan sinonim

— Rachel

Saya melihat hasil edit Anda ... itulah tepatnya yang saya coba lakukan tetapi pertanyaan saya adalah apakah ini ide yang bagus atau tidak, dan jika tidak, mengapa?

— Rachel

Tidak apa-apa. Jika Anda setuju membuat 2 aplikasi berita sepenuhnya bergantung pada aplikasi pertama.