Wiele baz danych V / s

Zbudowałem tę aplikację internetową (php i mysql), która przechowuje informacje dla różnych organizacji (obecnie około 20 klientów).

Bieżący scenariusz przechowuje informacje związane z klientem w poszczególnych bazach danych, więc istnieje 20 baz danych klientów i 1 główna baza danych.

Jedną z głównych zalet jest to, że ponieważ każda baza danych klienta jest izolowana, numeracja artefaktów klienta (raporty, audyty) itp. Jest sekwencjonowana; dając naszym klientom poczucie bezpieczeństwa.

Każdy DB ma w przybliżeniu 15 tabel, a najwięcej wierszy w tabeli ma około 2000. Oczekuje się, że zostanie to maksymalnie zwiększone do 5000 rekordów.

Zarządzanie pojedynczą zmianą poziomu db oznacza zmianę 20 baz danych, ale w rzadkich przypadkach, gdy muszę wprowadzić taką zmianę, używam skryptu, który robi to w pojedynczym wywołaniu funkcji.

Jesteśmy na wspólnej platformie hostingowej, a nasz dostawca usług internetowych zapewnia nam ograniczoną liczbę nie. baz danych; i to właśnie skłoniło mnie do myślenia o scentralizowaniu bazy danych; aby WSZYSTKIE dane klienta mogły być przechowywane w głównej bazie danych.

Oczywiście pojawiają się następujące ważne kwestie:

za. Utrzymanie sekwencji artefaktów (można to rozwiązać, tworząc dodatkowy klucz referencyjny) b. Szybkość i wydajność (w takim przypadku mogę tworzyć indeksy w celu przyspieszenia rzeczy) c. Bezpieczeństwo: będzie zarządzany jako każde zapytanie, które pobiera informacje o kliencie. będzie również śledzić ich identyfikator_ klienta

W przyszłości być może będziemy musieli rozważyć porównanie zestawów danych jednej organizacji z inną, ale uważam, że można to osiągnąć również w scentralizowanym pliku danych. Jestem nieco skłonny (ze względu na wydajność i łatwość konserwacji) do przejścia do scentralizowanej bazy danych.

Czy uważasz, że przejście do scentralizowanej bazy danych ma większy sens niż pozostanie takim, jakim jesteśmy (w poszczególnych bazach danych)?

Dzięki za radę.

Oba systemy dziedziczą ryzyko i korzyści. Pracowałem dla firmy finansowej, która obsługiwała około 40 klientów (banków krajowych) w 1 bazie danych. Następnie kupiliśmy inną firmę, która sprzedawała podobne oprogramowanie i która posiadała 1 bazę danych na klienta. W końcu firma zbankrutowała i musieliśmy wyeksportować wszystkie dane użytkownika. Oto ludzie, z którymi pracowałem i które znalazłem:

Pro z Single DB:

1. Aktualizacje oprogramowania i poprawki błędów są łatwiejsze.
2. Łatwy w zarządzaniu i raportowaniu na wszystkich danych klienta.
3. Aktualizacja danych staje się łatwiejsza.
4. Łatwe tworzenie modułowej funkcjonalności, której chce jeden klient, wyłącz ją, jeśli chcesz, dla innych klientów, a następnie włącz ją, gdy tylko zechcą w przyszłości.

Con's of Single DB:

1. Integralność danych - mieliśmy 2 lub 3 przypadki, w których użytkownicy 1 banku widzieli dane innego banku. To był koszmar. Zwłaszcza, że ​​użytkownicy strony byli nie tylko pracownikami banku, ale faktycznymi klientami banku! Jest to zdecydowanie największy problem z 1 bazą danych
2. Eksportowanie danych klienta - kiedy to musieliśmy, zwykle nie było to nic wielkiego. Otrzymujesz 1 tabelę, w której są wszyscy klienci, i rezygnujesz z tej tabeli, aby uzyskać określone dane klienta.

Pro z wielu baz danych:

1. Nie ma obaw o zanieczyszczenie lub naruszenie danych między klientami
2. Eksportowanie danych klientów jest wyjątkowo łatwe.

Wady wielu baz danych:

1. Aktualizacje i poprawki błędów - To był prawdziwy koszmar. Gdy masz 20 klientów w 20 różnych bazach danych, szybko trafiasz na przypadek, w którym 1 klient chce naprawić błąd, a inny uważa, że ​​błąd jest funkcją lub nie chce ryzykować aktualizacji. Ponadto wystąpią sytuacje, w których 1 klient chce ulepszenia zmieniającego grę, a inni klienci tego nie robią. Gdy tak się stanie, bazy danych zaczną się rozchodzić. Nagle będziesz musiał zaktualizować klientów 1-15 z 1 skryptem 16-19 z innym, a 20 z trzecim. Zauważyliśmy, że stało się to tak dużym problemem, że usunięcie błędu zajęłoby 15 do 20 razy więcej czasu firmie, którą kupiliśmy, niż nam, ponieważ musieli oni przeprowadzić wszystkie testy dla każdego klienta i zająć się specjalnym kodem dla każdego klienta. Skutecznie potrzebowali nowej osoby obsługującej każdego nowego klienta,
2. Zarządzanie bazami danych - gdy dotrzesz do dużej liczby klientów, zarządzanie wszystkimi bazami danych staje się prawdziwym problemem. Bez wątpienia będziesz potrzebować więcej czasu na zarządzanie nimi.

W końcu moim zaleceniem, które widziałem i zrobiłem oba, jest „dyscyplina”! Myślę, że wybór wielu baz danych jest nieco lepszy, ponieważ chroni cię, ale nigdy nie możesz pozwolić klientom dokonać wyboru, który spowoduje, że dodasz funkcjonalność tylko do nich lub będziesz narażony na porażkę.

Miałbym osobną bazę danych dla oddzielnych klientów. Klient może tego wymagać ze względów bezpieczeństwa - tj. Tylko ich strona ma dostęp do swoich danych. Oznacza to również, że jeśli klient chce przenieść swoje dane to będzie dużo łatwiejsze do zarządzania.

Oznacza to również, że jeśli występuje problem z bazą danych jednego klienta, nie wpływa to na wszystkie pozostałe.

Jeśli chcesz porównać dane między klientami, powinieneś to zrobić osobno.

Jeśli brakuje Ci baz danych, które możesz mieć, być może powinieneś rozważyć zmianę dostawcy hosta.

Jedynym powodem, dla którego nie miałbym osobnej bazy danych dla każdego klienta, jest to, że masz 100 lub 1000 klientów / baz danych. Może to być naprawdę włochate w zarządzaniu, w tym wprowadzanie zmian w bazie danych lub robienie czegoś we wszystkich bazach danych. Działania wykonywane w wielu bazach danych mogą być również powolne, ponieważ trzeba otworzyć (a zatem zamknąć) tak wiele tabel.

Ale oprócz tego przypadku uważam, że wiele baz danych jest lepszych.

Jedną z zalet, która może nie być ważna, ale może być użyteczna, jest to, że każdy klient otrzymuje własne sekwencyjne identyfikatory (zamiast ewentualnego pomijania grupy, ponieważ inni klienci dodali rekordy).

Ponadto wiele baz danych pozwala łatwo dostosować tabele podrzędne (takie jak typ telefonu) dla każdego klienta bez potrzeby posiadania identyfikatora rekordu nadrzędnego w tych tabelach.

Najpierw sekwencjonowanie artefaktów. Zakładam, że do tego celu używasz liczb całkowitych. Naprawdę powinieneś mieć osobną kolumnę „numer artefaktu”. PK powinny być PK i niczym więcej. Ludzie mówią o „naturalnych kluczach” i tym podobnych, a ja kulę się. Ilekroć polegasz na tym, że PK jest czymś więcej niż identyfikatorem, wraca, by cię ugryźć. Jeśli chcesz poznać sekwencję czegoś, zapisz datę lub numer sekwencyjny.

Myślę, że w twoim przypadku zarządzanie konfiguracją doprowadziłoby cię do pojedynczej bazy danych. Zobacz, ile kosztuje utrzymanie i aktualizowanie baz danych. Jakie koszty wiążą się z każdą wersją oprogramowania? Zastanów się także nad kosztem, gdy pozyskasz nowego klienta i musisz utworzyć bazę danych i skonfigurować dla niej aplikację. Wszystko można zautomatyzować, pytanie brzmi: czy warto, jeśli masz 100 baz danych?

W przyszłości łatwiej jest skalować (partycjonowanie, sprzęt, dzielenie itp.) Pojedynczej bazy danych, niż zrobić to samo dla 100 baz danych.

Myślę, że inni plakaty napisali kilka doskonałych punktów, więc nie będę ich omijał.

Aby dodać do wymienionych dotychczas pro / conów:

Pro wielu baz danych:

1. Unika się problemów z blokowaniem; mamy bazy danych, w których klienci mogą wywoływać zmiany DDL w niektórych tabelach. W przypadku większych tabel (> 2m rekordów) blokuje to tabelę na znaczny czas. Jedynymi osobami w niekorzystnej sytuacji są ich użytkownicy, więc jest to w pewnym sensie dopuszczalne.

2. Elastyczność - niektórzy klienci mają określone życzenia dotyczące danych, które chcą przechowywać; multi-baza danych pozwoliła nam elastycznie modyfikować swoją bazę danych bez konieczności zaśmiecania modelu danych innych klientów.

Cons:

1. Major con: Dołączanie do innych stołów jest znacznie bardziej kłopotliwe. Mamy główną bazę danych, która zawiera większość metadanych. Użytkownicy bazy danych specyficzni dla klienta nie mają dostępu do tej bazy danych, więc wszystkie połączenia między tabelami w tej bazie danych a tabelą specyficzną dla klienta są obsługiwane w aplikacji zamiast w bazie danych. Możesz rozwiązać ten problem, dając użytkownikom specyficznym dla klienta dostęp do głównej bazy danych, ale wtedy aplikacja może / może ponownie ujawnić informacje.

Powodzenia w wyborze!

Wiem, że już wybrałeś odpowiedź, ale wygląda na to, że istnieje inne rozwiązanie, które nie zostało zasugerowane:

Przenieś wszystko do jednej bazy danych, ale utwórz tabele dla każdego klienta, używając prefiksu, takiego jak ten:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

To trochę najlepsze z obu światów.

• Migracja z bieżącej konfiguracji do nowej konfiguracji jest bardzo łatwa.
• Możesz utworzyć 1 użytkownika na klienta i ograniczyć jego uprawnienia do tabel jego firmy i nic więcej
• Możesz utworzyć superużytkownika i łatwo agregować dane, jeśli zajdzie taka potrzeba.
• Użyj tylko jednej bazy danych