Żałujesz, że nie używałeś oddzielnych baz danych:
- Jeśli kiedykolwiek będziesz chciał przyznać uprawnienia do samych baz danych klientom lub superużytkownikom.
- Jeśli kiedykolwiek będziesz chciał przywrócić bazę danych tylko jednego klienta bez wpływu na dane innych.
- Jeśli istnieją obawy regulacyjne dotyczące naruszenia danych i danych, a poniewczasie odkryjesz, że przepisy te można spełnić tylko dzięki osobnym bazom danych. (Aktualizacja:nieco ponad 4 lata po napisaniu tej odpowiedzi RODO weszło w życie)
- Jeśli kiedykolwiek zechcesz łatwo przenieść dane klientów na wiele serwerów baz danych lub w inny sposób skalować lub przenieść większych/ważniejszych klientów na inny sprzęt. W innej części świata.
- Jeśli kiedykolwiek będziesz chciał łatwo archiwizować i likwidować stare dane klientów.
- Jeśli Twoim klientom zależy na silosowaniu ich danych i dowiedzą się, że Ty zrobiłeś inaczej.
- Jeśli Twoje dane są wezwane i trudno jest wyodrębnić dane tylko jednego klienta, lub wezwanie sądowe jest zbyt szerokie i musisz stworzyć całą bazę danych zamiast tylko danych dla jednego klienta.
- Gdy zapomnisz zachować czujność i prześlizgnie się tylko jedno zapytanie, które nie zawierało
AND CustomerID = @CustomerID. Wskazówka:użyj skryptowego narzędzia uprawnień lub schematów, albo otocz wszystkie tabele widokami zawierającymiWHERE CustomerID = SomeUserReturningFunction()lub ich kombinację. - Gdy uzyskasz nieprawidłowe uprawnienia na poziomie aplikacji, a dane klienta zostaną udostępnione niewłaściwemu klientowi.
- Gdy chcesz mieć różne poziomy ochrony kopii zapasowych i odzyskiwania dla różnych klientów.
- Kiedy zdasz sobie sprawę, że budowanie infrastruktury do tworzenia, udostępniania, konfigurowania, wdrażania i w inny sposób rozkręcania nowych baz danych jest warte inwestycji, ponieważ zmusza Cię do osiągnięcia w tym dobrego.
- Gdy nie uwzględniłeś możliwości, że jakaś klasa ludzi potrzebuje dostępu do danych wielu klientów i potrzebujesz warstwy abstrakcji na wierzchu
CustomerponieważWHERE CustomerID = @CustomerIDteraz go nie przetnie. - Gdy hakerzy atakują Twoje witryny lub systemy, a Ty ułatwiłeś im uzyskanie wszystkich danych wszystkich klientów za jednym zamachem po uzyskaniu danych logowania administratora w zaledwie jednym baza danych.
- Kiedy tworzenie kopii zapasowej bazy danych trwa 5 godzin, a następnie kończy się niepowodzeniem.
- Kiedy musisz pobrać wersję Enterprise swojego DBMS, aby móc tworzyć skompresowane kopie zapasowe, dzięki czemu kopiowanie pliku kopii zapasowej przez sieć zajmuje mniej niż 5 godzin więcej .
- Kiedy musisz codziennie przywracać całą bazę danych na serwer testowy, co zajmuje 5 godzin, i uruchamiać skrypty weryfikacyjne, których ukończenie zajmuje 2 godziny.
- Gdy tylko kilku Twoich klientów potrzebuje replikacji i musisz zastosować ją do wszystkich swoich klientów, a nie tylko do tych kilku.
- Gdy chcesz zająć się klientem rządowym i dowiadujesz się, że wymaga on użycia oddzielnego serwera i bazy danych, ale Twój ekosystem został zbudowany wokół jednego serwera i bazy danych i jest to po prostu zbyt trudne lub zmiana zajmie zbyt dużo czasu .
Będziesz zadowolony, że korzystasz z osobnych baz danych:
- Kiedy wdrożenie pilotażowe dla jednego klienta całkowicie eksploduje, a pozostałych 999 klientów nie ma żadnego wpływu. I możesz przywrócić z kopii zapasowej, aby rozwiązać problem.
- Gdy jedna z kopii zapasowych Twojej bazy danych nie powiedzie się i możesz naprawić tylko tę w 25 minut, zamiast rozpoczynać cały 10-godzinny proces od nowa.
Żałujesz, że nie używałeś jednej bazy danych:
- Kiedy odkryjesz błąd, który dotyczy wszystkich 1000 klientów, a wdrożenie poprawki do 1000 baz danych jest trudne.
- Gdy uzyskasz nieprawidłowe uprawnienia na poziomie bazy danych, a dane klienta zostaną udostępnione niewłaściwemu klientowi.
- Gdy nie zezwoliłeś na możliwość, że jakaś klasa ludzi potrzebuje dostępu do podzbioru wszystkich baz danych (być może połączenie dwóch klientów).
- Kiedy nie zastanawiałeś się, jak trudno byłoby połączyć dwie różne bazy danych.
- Kiedy połączysz dwie różne bazy danych i zdasz sobie sprawę, że jedna była niewłaściwa i nie planowałeś odzyskiwania z tego scenariusza.
- Gdy spróbujesz przekroczyć 32 767 klientów/baz danych na jednym serwerze i przekonasz się, że jest to maksimum w SQL Server 2012.
- Kiedy zdasz sobie sprawę, że zarządzanie ponad 1000 baz danych jest większym koszmarem, niż kiedykolwiek sobie wyobrażałeś.
- Kiedy zdasz sobie sprawę, że nie możesz wprowadzić nowego klienta tylko przez dodanie danych do tabeli i musisz uruchomić kilka przerażających i skomplikowanych skryptów, aby utworzyć, wypełnić i ustawić uprawnienia w nowej bazie danych.
- Kiedy musisz codziennie wykonywać 1000 kopii zapasowych bazy danych, upewnij się, że wszystkie się powiodły, skopiuj je przez sieć, przywróć je wszystkie do testowej bazy danych i uruchom skrypty sprawdzania poprawności na każdym z nich, zgłaszając wszelkie awarie w sposób, który zagwarantuje, że będą widoczne, a które można łatwo i szybko wykonać. A potem 150 z nich ulega awarii w różnych miejscach i trzeba je naprawiać pojedynczo.
- Kiedy dowiesz się, że musisz skonfigurować replikację dla 1000 baz danych.
To, że wymieniłem więcej powodów dla jednego, nie oznacza, że jest lepszy.
Niektórzy czytelnicy mogą uzyskać wartość z MSDN:Multi -Architektura danych najemcy . A może Wzorce projektowania aplikacji dzierżawy SaaS . Lub nawet Programowanie dla wielu dzierżawców Aplikacje dla chmury, 3. edycja
