Pojedyncze lub oddzielne bazy danych dla oddzielnych kont klientów?

Question

Pracuję nad aplikacją, która zbiera dane z kart inteligentnych. Chcę móc uruchomić aplikację jako usługę internetową dla wielu kont klientów. Pytanie brzmi, czy powinienem utworzyć osobną bazę danych dla każdego konta, czy też powinienem zaprojektować pojedynczą bazę danych przechowującą dane wszystkich kont? Po pierwsze pomyślałem, że jedna baza danych jest oczywistą odpowiedzią, ale powoduje, że AccountID musi być używany niemal wszędzie, w tabelach, indeksach, ograniczeniach, zapytaniach, czekach itp.

W tej aplikacji nie ma jeden bajt danych, które mają być współdzielone między kontami.

pierwsze, przyjrzyjmy się, jak będzie wyglądać oddzielne bazy danych dla jednego konta:

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30)); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30)); 

Dodajmy do tego kilku unikalności ograniczeń,

ALTER TABLE CardHolder ADD CONSTRAINT UQ_CardHolderName UNIQUE (CardHolderUniqueName); 
ALTER TABLE SmartCard ADD CONSTRAINT UQ_CardName UNIQUE (CardUniqueName); 

Teraz, jeśli mogę umieścić wszystko w jednej bazie danych oznacza to, że kilka kont może obsługiwać te same CardHolders i SmartCards, ale konta nie powinny widzieć siebie nawzajem. Z tego powodu karta SmartCard jest unikalna na koncie, ale nie w całej bazie danych. Tak więc, każdy ograniczenie musi zawierać accountid,

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30), 
    AccountID int); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30) 
    AccountID int); 

ALTER TABLE CardHolder 
    ADD CONSTRAINT UQ_CardHolderName UNIQUE (AccountID, CardHolderUniqueName); 
ALTER TABLE SmartCard 
    ADD CONSTRAINT UQ_CardName UNIQUE (AccountID, CardUniqueName); 

w rzeczywistej DB, nie będzie mnóstwo więcej tabel, kolumn i kilka indeksów (dla Zamieszczone przez expirydate etc etc), a kolumna identyfikator konta musi być włączone wszędzie .

Wydaje mi się, że jestem trochę zagracony, najpierw umieszczając wszystkie konta w pojedynczej bazie danych, a następnie rozdzielając je poprzez posiadanie kolumny AccountID w każdej tabeli i prawie każdym ograniczeniu i indeksie. Potrzebowałabym też znaleźć lub wymyślić jakieś zabezpieczenia na poziomie wiersza, aby uniemożliwić użytkownikom dostęp do danych innych kont. Czy mam uzasadnioną wymówkę dla tworzenia oddzielnej bazy danych dla każdego konta, czy też "prawdziwi projektanci db" zawsze przechowują wszystko w jednej bazie danych?

Answer 1

Podczas projektowania aplikacji dla wielu dzierżawców należy pamiętać o kilku kwestiach, w tym - jak Państwa pytanie - o projekcie schematu, ale należy również wziąć pod uwagę takie kwestie, jak koszty licencji, skalowalność itp. This article describes the three most common approaches for designing a multi-tenant application, w tym za i przeciw. Sprawdź to.

Answer 2

IMHO jest tylko jeden sposób. Wiele baz danych.

1. to nie tylko w pełni bezpieczne dane, które muszą być NIGDY udostępnionego
2. Umożliwia również schematy zmieniać niezależnie od siebie. Rozumiem przez to, że z biegiem czasu może jeden lokator jest znacznie większy niż wszystkie inne teananty, a zatem trzeba zaspokoić specjalne potrzeby.
3. kopii zapasowej, przywracania i strategie mogą być łatwo formułowane przez niezależnych bazach
4. ograniczeń i niepowtarzalność są łatwiejsze i bardziej naturalnie wyrażone

Answer 3

Mamy spadły obie trasy tutaj. Mamy wspólną bazę danych dla mniejszych klientów, którzy nie potrzebują personalizacji i osobną bazę danych (i podstawę kodu aplikacji) dla klientów korporacyjnych, którzy to robią.

Obie mają swoje plusy i minusy. W udostępnionej bazie danych wystarczy jedna zła kwerenda, w której ktoś zapomniał użyć identyfikatora klienta, a dane są wystawione na innych klientów.Za pięć lat widziałem to tylko raz, ale to był wielki koszmar, który kosztował nas klienta. Jeśli jedziesz tą trasą, upewnij się, że masz dobry zespół kontroli jakości, który dokładnie sprawdza to przed zwolnieniem kodu. Jeśli baza danych zawiera schematy, można użyć widoków w schematach, aby uniemożliwić dostęp do danych innych klientów. Jeśli klient ma tylko prawa do swoich wyświetleń, może nigdy nie zobaczyć danych innych osób. Jest to jednak więcej pracy do skonfigurowania.

Jednak oddzielne bazy danych mogą stać się koszmarem, aby dokonać zmian w konserwacji. Jednakże, jeśli sprzedajesz swoje uaktualnienia, jest to sposób na to, że nie każdy klient kupi każde uaktualnienie. Po prostu upewnij się, że masz dobry mechanizm śledzenia, aby dowiedzieć się, w jakiej wersji działa każdy klient i czy używasz kontroli źródła do śledzenia wszystkich zmian w bazie danych według wersji, abyś mógł łatwo dokonać aktualizacji.

Jeśli nie zamierzasz mieć dostosowań, może się okazać, że i tak oddzielne bazy danych prowadzą w tym kierunku. O wiele łatwiej jest im powiedzieć, że nie, kiedy są wspólną bazą danych.

Ponadto stwierdziliśmy, że istnieją dostosowania, które byłyby pomocne dla innych klientów, ale dlatego, że zostały opracowane w oddzielnej aplikacji i bazie danych, są ponownie opracowywane przez inny zespół dla innego klienta, a kończy się na 6 sposobach zrobić to samo. Staje się to poważnym problemem dla osób, które pracują z klientami, takimi jak ludzie, którzy importują dane klientów do baz danych. Osobiście preferuję podejście oparte na jednej bazie danych.

Kolejna kwestia dotycząca potrzeby konsolidacji lub oddzielenia kwestii zgłaszania danych. Jeśli raportowanie zawsze będzie wykonywane tylko przez klienta, możesz je rozdzielić, ale jeśli potrzebujesz raportów (takich jak własne wewnętrzne raporty finansowe) na skonsolidowanych danych, jest to znacznie łatwiejsze, jeśli masz skonsolidowaną bazę danych. Wychodzę z tego, ponieważ ludzie zapominają o raportowaniu do czasu, aż projekt zostanie ustawiony i może to spowodować dość nieprzyjemne problemy, kiedy to zrobisz.