Yinelenen bir tablo oluşturmaktan kaçınmak için Eş anlamlıları kullanmak iyi bir fikir mi?

Aynı veritabanının 3 kopyası var. 3 veritabanının hepsinde bir Userstablo vardır ve bir Kullanıcı her zaman aynı ayarlara sahip 3 veritabanında bulunur. Bir Kullanıcı eklemek veya düzenlemek istediğimizde 3 veritabanını güncellememiz gerekir.

UsersTablo 2 ve 3 veritabanından silmek ve Synonymveritabanını 1 işaret eden bir ile değiştirmek daha iyi bir fikir olabilir mi ?

İşte aklıma gelen artıları / eksileri:

Artıları

• Daha Kolay Bakım. Kullanıcıları 3 yerine tek bir konumda güncelleyebilir
• Kullanıcı Kimlikleri veritabanları arasında eşleşir (Çok sayıda eklenti uygulaması UserId'yi temel aldığından önemlidir)

Eksileri

• Bunun standart bir prosedür olduğunu düşünmeyin, bu yüzden kafa karıştırıcı olabilir
• Kullanıcıların veritabanları arasında aynı ayarlara sahip olması gerekir
• ( Aşağıdaki gbn'nin cevabından ) Veri Tabanı 1 aşağı düşerse, Veri Tabanı 2 ve 3 de kullanılamaz. Ayrıca geri yükleme durumunda verilerin tutarsız olmasıyla ilgili potansiyel bir sorun vardır

Bu, sadece Userstablo değil, veritabanları arasında aynı olan ayarları içeren birkaç farklı tablo için düşündüğüm bir seçenektir . Anlamak kolay olduğu için örnekte Kullanıcılar kullanıyorum.

Neden aynı kullanıcılarla 3 veritabanınız var?

Bir veritabanı şimdi kapanırsa ne olur?

Bu iki soruyu soruyorum çünkü diğer iki veritabanının kullanımını engelleyen kullanıcı kaynaklı veritabanının Con sesi göründüğü kadar büyük bir sorun olmayabilir.

Ayrıca, bir veritabanı artık kapanırsa, kullanıcılar bu süre zarfında diğer iki DB'de değiştirildiyse zaten tutarlılık sorunlarınız olacaktır. Daha fazla bağlam olmadan en iyi tavsiyeyi verebileceğimizi sanmıyorum.

Şu anda kullanıcılar için dördüncü bir veritabanı oluşturacağım, sadece orada değişiklikler yapacağım ve diğer veritabanlarında senkronize edeceğim. Aynı verileri üç yerde değiştirerek zaten dağıtılmış durumdasınız ve muhtemelen tutarlılık problemleriniz var. Hata toleransı önemliyse, bu şema yine de çoklu giriş problemini çözerken bunu verir.

Mevcut kaynaklardan birini kullanmak yerine bu dördüncü kullanıcı / yalnızca ayar veritabanına sahip olmanın iyi bir strateji olduğunu düşünüyorum çünkü diğer kaynaklara bağlı olmadığı veya yoğun bir şekilde kullanılmadığı için aşağı gitme olasılığı daha düşük. Şimdi bunu yapamayacağınızı söylediğinizi görüyorum, ama nedenini açık değilim. Ana veritabanındaki uygulamalar kullanıcının doğrudan düzenlemesini destekliyor mu veya kullanıcı başka bir yere işaret edebilecek tamamen ayrı bir işlevi mi düzenliyor?

Doğru, bu "kanonik kullanıcı tablosu" fikri ile - eşanlamlıları kullanın ya da verileri senkronize edin - aşağı kullanıcı DB sırasında kullanıcıları değiştiremezsiniz, ancak bu bana iyi geliyor. Sorunu giderin ve getirin! Bir kaynak, bir düzenleme yeri, kırılırsa düzeltilecek bir şey. Senkronizasyon ile diğer tüm veritabanlarında çalışabilecekleri geçici kopyalar bulunur, ancak düzenleme yapılmaz. Sistemler arasında veri çoğaltmayı en aza indirmek harika ve kullanışlı bir hedeftir. Aynı verileri üç yere girmek ciddi bir sorundur, bu yüzden bunu ortadan kaldırmak için elinizden geleni yapın.

Yorumlarınızın daha fazlasını ele almak için, kullanıcı kimlikleriniz tüm uygulamalarınızda farklıysa, iki yeni veritabanınızın bunları ana veritabanıyla senkronize etmeleri için planlanan bir kesinti süresini ciddiye almalısınız (fikirlere ihtiyacınız varsa ayrı bir soru sorun) bu nasıl başarılır, ki bu zor ama gerçekten zor değil).

İşletmenizin ihtiyaçlarını analiz ederseniz ve ana veritabanının iyi kullanıcı verilerine sahip olması gerektiğini tespit ederseniz, yine de kanonik olarak kullanırsınız, ardından eşzamanlı olmayan zamanların tüm veritabanlarını nasıl etkilediğini ele almak için eşanlamlılar veya senkronizasyon arasında seçim yaparsınız.

Eş anlamlıları kullanmaya yönelik ek bir Con, artık her veritabanında Kullanıcılara uygun FK'lere sahip olamayacağınızdır.

Eksik bir "Con" var

Geri yükleme sırasında, kullanıcınızın hedef (eş anlamlı) veritabanında bulunmaması mümkündür. Bozuk olduğunu ve bir yedeklemeden geri yüklemeniz gerektiğini söyleyin.

Yani, eşanlamlıların kullanımı, gerçek hayatta gerçekleşemeyen veritabanları arası referans bütünlüğünü varsayacaktır.

Bundan başka bir sonuç, bundan kurtulmaya çalıştığınızda uyuşmayan kullanıcı kimliği olacaktır. (geri yüklemeden sonra kullanıcıyı ekleyerek). Ancak, bahsettiğim veritabanları arası bilgi bütünlüğü nedeniyle bu hiçbir zaman varsayılmamalıdır.

Yani, yapma ...

Dba.se ile ilgili bir cevap: Geri yüklendikten sonra "veritabanları arası bilgi bütünlüğü" hakkında yeni bir veritabanı vs dbo olmayan bir şema ne zaman kullanılacağına ilişkin karar kriterleri

Veritabanı platformunuza bağlı olarak, başka bir seçenek de veritabanları 2 ve 3'teki tabloları silmek ve bunları veritabanı 1'deki tablonun materyal görünümleriyle değiştirmektir .

Artıları

• Daha Kolay Bakım (Verilerin)
• Eşleşen Kimler
• Kesintiler diğer veritabanlarını etkilemez (en azından değişiklik yapılması gerekene kadar)
• Tabloyu kurtarmak için herhangi bir veritabanı kullanılabilir.

Eksileri

• Veriler yalnızca yenileme programınız kadar günceldir.
• Tablo tanımı değişirse, somutlaştırılmış görünümlerin de değiştirilmesi gerekebilir.

Ayrıca, arama sıklığına, yenileme sıklığına ve veri değiştirme sıklığına bağlı olarak, bunun eş anlamlı bir çözümden daha fazla yük getirebileceğini veya getirmeyebileceğini unutmayın.

Güncelleme: FrustratedWithFormsDesigner'ın yorumu aslında materyalize görünümler yapamayan platformlar için bir Malzeme Görünümüdür. Bir komut dosyası kullanarak tablolar periyodik olarak senkronize edilebilir. Bir veritabanı asıl olarak atanırsa, tüm komut dosyaları değişikliklerini buna göre yapabilir. Bu, somutlaştırılmış bir görüşün tüm artılarını ve eksilerini olacaktır; yerleşik işlevsellikten yararlanamaz.

Paylaşılan Kullanıcı Bilgilerini saklayan bir 4. DB oluştururdum. Kullanıcılar DB'yi işaret eden Diğer Dbs'lerin her birini oluşturun Synonymsveya oluşturun Views.

Son olarak, bu uygulamaya özgü kullanıcı verilerini tutan 3 mevcut dbs her birinde bir uzantı tablosu ('UserDB.Usertable' ile bir-bir ilişkisi olan bir tablo) oluşturacaktı.

Düzenleme: Aşağıdaki yoruma göre

Bu durumda, First db'yi Master kullanıcı tablosu olarak hareket ettirin. Synonymsve Diğer Dbs'lerin her birinde bir uzatma tablosu.

Önemli not : Bu yaklaşımla, İlk uygulamanız düşerse, diğer ikisi onunla birlikte aşağı çekilir! Herkesin bu dezavantajı anladığından emin olun.