Czy warto używać synonimów, aby uniknąć tworzenia zduplikowanej tabeli?

Mamy 3 kopie dokładnie tej samej bazy danych. Wszystkie 3 bazy danych mają Userstabelę, a użytkownik zawsze będzie istniał we wszystkich 3 bazach danych z dokładnie takimi samymi ustawieniami. Za każdym razem, gdy chcemy dodać lub edytować użytkownika, musimy zaktualizować 3 bazy danych.

Czy lepiej byłoby usunąć Userstabelę z baz danych 2 i 3 i zastąpić ją Synonymwskazującą na bazę danych 1?

Oto zalety / wady, o których mogę myśleć:

Plusy

• Łatwiejsza konserwacja. Może aktualizować użytkowników w jednym miejscu zamiast 3
• Identyfikatory użytkowników pasowałyby między bazami danych (ważne, ponieważ wiele aplikacji dodatkowych opiera się na UserId)

Cons

• Nie myśl, że to standardowa procedura, więc może być myląca
• Użytkownicy musieliby mieć identyczne ustawienia między bazami danych
• (Z odpowiedzi gbn poniżej) Jeśli baza danych 1 kiedykolwiek ulegnie awarii, bazy danych 2 i 3 również będą niedostępne. Istnieje również potencjalny problem niespójności danych w przypadku przywracania

Jest to opcja, którą rozważam dla kilku różnych tabel zawierających Ustawienia, które są identyczne między bazami danych, a nie tylko Userstabelą. Korzystam z użytkowników w tym przykładzie, ponieważ jest to łatwe do zrozumienia.

Dlaczego masz 3 bazy danych z tymi samymi użytkownikami?

Co się stanie, jeśli jedna baza danych ulegnie awarii?

Zadaję te pytania, ponieważ spadek bazy danych użytkownika uniemożliwiający korzystanie z dwóch pozostałych baz danych może nie być tak dużym problemem, jak się wydaje.

Dodatkowo, jeśli baza danych ulegnie awarii, będziesz mieć już problemy ze spójnością, jeśli użytkownicy zostaną zmodyfikowani w pozostałych dwóch bazach danych w tym okresie. Nie sądzę, że możemy udzielić najlepszej porady bez większego kontekstu.

W tej chwili utworzę czwartą bazę danych dla użytkowników, wprowadzę zmiany tylko tam i zsynchronizuję inne bazy danych. Jesteś już zdecentralizowany, zmieniając zasadniczo te same dane w trzech miejscach i prawdopodobnie masz już problemy ze spójnością. Jeśli tolerancja na uszkodzenia jest ważna, ten schemat nadal daje to podczas rozwiązywania problemu wielokrotnego wejścia.

Myślę, że posiadanie czwartej bazy danych tylko dla użytkowników / ustawień zamiast jednej z istniejących jest dobrą strategią, ponieważ jest mniej prawdopodobne, że ulegnie awarii, ponieważ nie jest związana z innymi zasobami lub jest intensywnie używana. Widzę teraz, że powiedziałeś, że nie możesz tego zrobić, ale nie jestem pewien, dlaczego. Czy aplikacje w głównej bazie danych obsługują edycję użytkownika bezpośrednio, czy też użytkownik edytuje całkowicie oddzielną funkcję, którą można wskazać w innym miejscu?

To prawda, że ​​dzięki tej idei „kanonicznej tabeli użytkowników” - bez względu na to, czy używasz synonimów, czy synchronizujesz dane - nie możesz modyfikować użytkowników podczas niedziałającej bazy danych użytkownika, ale wydaje mi się to w porządku. Napraw problem i przywołaj go! Jedno źródło, jedno miejsce do edycji, jedna rzecz do naprawy, jeśli jest zepsuta. Dzięki synchronizacji wszystkie inne bazy danych mają tymczasowe kopie, z których mogą pracować, ale bez edycji. Minimalizacja duplikacji danych w różnych systemach jest doskonałym i użytecznym celem. Wprowadzanie tych samych danych w trzech miejscach jest poważnym problemem, więc zrób wszystko, co możesz, aby to wyeliminować.

Aby odpowiedzieć na więcej komentarzy, jeśli Twoje identyfikatory użytkowników są różne we wszystkich aplikacjach, powinieneś poważnie rozważyć planowany czas przestoju dwóch nowych baz danych, aby zsynchronizować je z główną (z osobnym pytaniem, jeśli potrzebujesz pomysłów jak to osiągnąć, co jest trudne, ale wcale NIE TAKIE trudne).

Jeśli przeanalizujesz potrzeby biznesowe i stwierdzisz, że główna baza danych musi mieć prawidłowe dane użytkownika, nadal używasz jej jako kanonicznej, a następnie wybierasz między synonimami lub synchronizacją, aby określić, w jaki sposób nieplanowane przestoje wpływają na wszystkie bazy danych.

Dodatkową wadą używania synonimów jest to, że nie byłoby już możliwe posiadanie odpowiednich FK dla użytkowników w każdej bazie danych.

Brakuje „Con”

Podczas przywracania możliwe jest, że użytkownik nie będzie istniał w docelowej (synonimowej) bazie danych. Powiedz, że jest uszkodzony i musisz przywrócić z kopii zapasowej.

Oznacza to, że użycie synonimów zakłada integralność referencyjną między bazami danych, co nie może się zdarzyć w prawdziwym życiu.

Inną konsekwencją tego byłyby niedopasowane identyfikatory użytkownika podczas próby odzyskania z tego. (dodając użytkownika po przywróceniu). Jednak nigdy nie należy tego zakładać z powodu integralności referencyjnej między bazami danych, o której wspomniałem.

Więc nie rób tego ...

Powiązana odpowiedź na stronie dba.se: Kryteria decyzyjne dotyczące użycia schematu innego niż dbo w porównaniu z nową bazą danych o „integralności referencyjnej między bazami danych” po przywróceniu

W zależności od platformy bazy danych inną opcją jest usunięcie tabel w bazach danych 2 i 3 i zastąpienie ich zmaterializowanymi widokami tabeli w bazie danych 1.

Plusy

• Łatwiejsza konserwacja (danych)
• Pasujące identyfikatory
• Awarie nie wpływają na inne bazy danych (przynajmniej do momentu wprowadzenia zmian)
• Do odzyskania tabeli można użyć dowolnej bazy danych.

Cons

• Dane są tylko tak aktualne, jak harmonogram odświeżania.
• Jeśli definicja tabeli ulegnie zmianie, zmaterializowane widoki również mogą wymagać zmian.

Należy również pamiętać, że w zależności od częstotliwości wyszukiwania, częstotliwości odświeżania i częstotliwości zmiany danych może to, ale nie musi, powodować większe obciążenie niż rozwiązanie synonimiczne.

Aktualizacja: komentarz FrustratedWithFormsDesigner jest zasadniczo widokiem zmaterializowanym dla platform, które nie mogą tworzyć widoków zmaterializowanych. Za pomocą skryptu tabele mogą być okresowo synchronizowane. Jeśli jedna baza danych zostanie wyznaczona jako główna, wówczas wszystkie skrypty mogą dokonywać na jej podstawie zmian. Miałoby to wszystkie zalety i wady zmaterializowanego poglądu; po prostu nie mógł skorzystać z wbudowanej funkcjonalności.

Chciałbym utworzyć 4. bazę danych, która przechowuje udostępnione informacje o użytkowniku. Utwórz Synonymslub Viewsw każdym innym Dbs, wskazując na DB użytkowników.

Na koniec utworzę tabelę rozszerzeń (tabelę z relacją One-one z „UserDB.Usertable”) w każdym z 3 istniejących DBS, która przechowuje dane użytkownika specyficzne dla tej aplikacji.

Edycja: na podstawie poniższego komentarza

W takim przypadku ustaw pierwszą bazę danych jako główną tabelę użytkowników. Synonymsoraz tabelę rozszerzeń w każdym innym Dbs.

Ważna uwaga : przy takim podejściu, jeśli twoja pierwsza aplikacja ulegnie awarii, pozostałe dwie zostaną z nią usunięte! Upewnij się, że wszyscy rozumieją tę wadę.