Wiele dzierżawców - jedna baza danych a wiele baz danych

20

Mamy wielu klientów, których systemy mają pewną funkcjonalność, ale mają też dość dużą różnorodność. Rośnie liczba klientów - zawsze zdrowa rzecz! - a różnorodność między ich firmami również rośnie.

Obecnie istnieje jedna witryna sieci Web ASP.Net (formularze WWW) (w przeciwieństwie do projektu internetowego), która zawiera podfoldery dla każdego najemcy, wraz z niestandardowymi stronami tego najemcy. Istnieje osobny projekt modelowy, który zajmuje się dostępem do bazy danych i logiką biznesową.

Co jest lepsze - a co najważniejsze - dlaczego - między posiadaniem (a) 1 bazy danych na klienta, z tylko funkcjami powiązanymi z tym klientem; lub (b) pojedyncza baza danych współdzielona przez wszystkich klientów, przy czym tylko jeden zestaw tabel jest używany przez jednego klienta.

Główne obawy w branży dotyczą:

utrzymanie wielu zasobów - kopii zapasowych, kontrola wersji i tym podobne
promowanie ponownego wykorzystania w jak największym stopniu

W jaki sposób zapewniłbyś rozwiązanie tych problemów, które rozwiązanie jest lepsze i dlaczego? (Kompilowałem również odpowiedzi na podobne pytania)

database-design projects-and-solutions multitenancy

— RichardW1001
źródło

Czy jest szansa, że przeniesie się to do środowiska chmury PaaS, takiego jak Azure? Jeśli tak, warto rozważyć najlepsze praktyki dotyczące środowiska. Ostatnim razem, gdy szukałem, MS zalecało wiele baz danych dla oprogramowania obsługującego wiele podmiotów na platformie Azure.

— Harper Shelby

Dzięki, że pytasz. Zastanawiałem się nad podobnymi rzeczami, ale nie byłem w stanie tak kwestionować formatu, jak ty.

— MathAttack

Powinieneś przeczytać serię blogów Ayende dla wielu najemców. Mówi bardzo dobrze o wielu bazach danych.

— Sebazzz,

12

Oto najważniejsze informacje z badań z innych źródeł (pierwotnie z wersji 2 pytania ):

Czy powinienem używać jednej bazy danych na aplikację lub udostępniać jedną bazę danych wielu aplikacjom
Wspieranie multitenancy
MSDN Multi-Tenant Data Architecture
SO Jak stworzyć bazę danych dla wielu dzierżawców ze wspólnymi strukturami tabel?
CloudExpo SaaS - Opcje projektowania baz danych dla wielu najemców
Blogi MSDN Przejście na model bazy danych wielu dzierżawców jest łatwiejszy dzięki federacjom SQL Azure
Zapytaj bazę danych SQL Server Central One lub wiele?
SQL Server Centralne mieszanie tabel z różnych baz danych / aplikacji w jedną bazę danych
Blog Ayende @ Rahien Multi Tenancy - model danych fizycznych
Code Project Architektura bazy danych wielu najemców
Joel o oprogramowaniu Projektowanie bazy danych dla wielu dzierżawców
SO Wiele aplikacji korzysta z jednej bazy danych?
SO Jedna lub wiele baz danych
Code Rant - Multi-tenancy Part 1, Strategy and Part 2, Components and Context

— 40980
źródło

10

Jeśli używasz programu SQL Server, użyj jednej bazy danych, ale użyj schematów. Użyj dbo do rzeczy ogólnych dla wszystkich klientów i utwórz schemat dla każdego klienta i ustaw domyślny schemat dla użytkowników z tego klienta. Teraz możesz mieć ogólny obiekt (na przykład proc getBudget) w schemacie dbo i dostosowany dla klienta w schemacie o tej samej nazwie.

— HLGEM
źródło

+1 Pozwoli to również uniknąć konieczności konfigurowania MSDTC i podjęcia związanego z tym narzutu (zatwierdzanie dwufazowe)

— brian

Mamy nadzieję, że unikniesz pułapki posiadania kolumn takich jak CustomField1 do CustomField30 i / lub posiadania tabel takich jak Budget, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName itp.

— jfrankcarr

Istnieje istniejąca warstwa dostępu do danych, która wykorzystuje wiele procedur przechowywanych - 190 tabel, 5 procedur wygenerowanych przez kod na tabelę oraz niektóre niestandardowe - podczas gdy średniookresowym celem jest wprowadzenie Entity Framework, czy istnieje potrzeba replikacji przechowywanych procedury dla każdego schematu?

— RichardW1001

@ RichardW1001: zależy. możesz zrobić dynamiczny SQL w sp, aby uczynić go ogólnym, ale to oczywiście zależy od tego, że mają co najmniej nieco podobną strukturę. Możliwą alternatywą dla dynamicznego sql, byłyby Synonimy , niestety, jak rozumiem, są one systemowe i nie zawierają się w transakcji, więc nie nadają się do jednoczesnego użycia z różnymi wartościami.

— jmoreno

Jeśli używamy wielu schematów, używając najpierw kodu EF, czy będzie możliwa migracja wszystkich schematów do najnowszej wersji po uruchomieniu systemu?

— Yashvit

4

Ponieważ bazy danych klientów i funkcje są rozbieżne, oznacza to, że w pewnym momencie będą to różne systemy, więc w tym przypadku zaleciłbym osobne systemy, ponieważ koszty utrzymania dostosowań dla każdego klienta przeważą nad korzyściami pojedynczego system bazy danych.

Systemy z pojedynczą bazą danych są najlepsze, gdy zmiany między różnymi klientami są jedynie konfiguracjami, ale nie dodatkowymi funkcjami dla każdego klienta.

— Stephen Senkomago Musoke
źródło

Jaka byłaby Twoja sugestia, jak zarządzać wspólną funkcjonalnością przy minimalnym bólu?

— RichardW1001

1

W swoim systemie kontroli wersji utrzymuj kierownictwo głównej aplikacji i utwórz główną gałąź dla każdego klienta, z pod-gałąź dla nowych funkcji, które muszą utrzymywać. Rozwijaj specyficzne dla klienta funkcje w oddziałach, z opcjami aktualizacji pnia itp. Następnie możesz z łatwością rozwijać środowiska specyficzne dla klienta, ilekroć ich potrzebujesz

— Stephen Senkomago Musoke

3

Brakuje Ci pewnych obaw. Problemy pojawią się wraz ze wzrostem. Jeśli możesz założyć, że pewnego dnia staniesz się większy niż jeden serwer DB - jedna złożona baza danych na pewno sprawi ci ból głowy. Chyba że wcześniej zainwestujesz w architekturę. Ale jest to również kosztowny krok)

Nie zapominaj więc, że zarówno wiele razy taniej, jak i wiele razy łatwiej skalować kilka różnych baz danych niż ogromne)

— stymulacja
źródło

Czy masz jakieś dane potwierdzające łatwość skalowania? Jeśli tak, byłby to bardzo przekonujący przypadek. Czy mógłbyś rozwinąć inne brakujące obawy? Staram się zbudować jak najbardziej kompletny argument po obu stronach, jak to możliwe.

— RichardW1001

1

Jednym z obszarów, których nie widziałem w odpowiedziach, są problemy z prawidłowym zabezpieczeniem aplikacji DB dla wielu dzierżawców. Aplikacje dla wielu dzierżawców muszą być bardzo starannie zaprojektowane, aby uniknąć problemów z bezpieczeństwem. Większość baz danych i aplikacji zapewnia pewną, ale nie całkowitą izolację - zwykle istnieją sposoby bezpośredniego lub pośredniego wnioskowania na podstawie schematów DB. I sporo wspólnych zasobów (dzienniki i inne pliki, tabele DBA, kursory ...), które mogą przynajmniej prowadzić do łatwych ataków typu „odmowa usługi” na innych najemców i zwykle znacznie więcej.

— Czapla
źródło