Czy powinienem używać jednej bazy danych na aplikację, czy udostępniać jedną bazę danych wielu aplikacjom [zamknięte]

Mam wiele aplikacji, które wykorzystują dane z tych samych źródeł. Czy najlepszą praktyką (lub jakie są zalety / wady) jest:

• pozostaw dane w bazach danych współdzielonych przez wiele aplikacji

  1. oszczędza miejsce, ponieważ potrzebna jest tylko jedna baza danych
  2. komplikuje indeksowanie, ponieważ różne aplikacje mają różne potrzeby dotyczące zapytań

• codziennie importuj dane do baz danych aplikacji

  1. zużywa więcej miejsca, ponieważ w bazach danych dla aplikacji istnieją zduplikowane dane
  2. łatwiejsze indeksowanie, ponieważ każda aplikacja może skupić się na swoich indywidualnych potrzebach

Mogłem pominąć inne zalety / wady, proszę wymienić, jeśli takie istnieją, a także jak to się robi w miejscu pracy?

Obecnie przestrzeń jest tania, dlatego radzę korzystać z jednej bazy danych na aplikację.

Udostępnianie jednej bazy danych wielu aplikacjom ma poważne wady :

• Im więcej aplikacji korzysta z tej samej bazy danych, tym bardziej prawdopodobne jest, że trafisz na wąskie gardła wydajności i że nie będziesz w stanie łatwo skalować obciążenia zgodnie z oczekiwaniami . Bazy danych SQL nie są tak naprawdę skalowane. Możesz kupić większe maszyny, ale nie są dobrze skalowane w klastrach!

• Koszty utrzymania i rozwoju mogą wzrosnąć : Programowanie jest trudniejsze, jeśli aplikacja musi korzystać ze struktur bazy danych, które nie są odpowiednie dla danego zadania, ale muszą być używane, ponieważ są już obecne. Jest również prawdopodobne, że korekty jednej aplikacji będą miały skutki uboczne w innych aplikacjach („dlaczego jest tak niepotrzebny wyzwalacz ??!” / „Nie potrzebujemy już tych danych!”). Jest już ciężko z jedną bazą danych dla jednej aplikacji, gdy programiści nie znają / nie znają wszystkich przypadków użycia.

• Administracja staje się trudniejsza: Który obiekt należy do której aplikacji? Chaos rośnie. Gdzie muszę szukać moich danych? Który użytkownik może wchodzić w interakcje z którymi obiektami? Co mogę komu przyznać?

• Aktualizacja: Potrzebujesz wersji, która jest najniższym wspólnym mianownikiem dla wszystkich aplikacji, które z niej korzystają. Oznacza to, że niektóre aplikacje nie będą mogły korzystać z zaawansowanych funkcji. Będziesz musiał trzymać się starszych wersji. Zwiększa również nieco koszty rozwoju.

• Współbieżność: czy naprawdę możesz być pewien, że nie ma chronologicznych zależności między procesami? Co się stanie, jeśli jedna aplikacja zmodyfikuje dane, które są nieaktualne lub powinny zostać najpierw zmienione przez inną aplikację? Co z różnymi aplikacjami działającymi jednocześnie na tych samych tabelach?

W porównaniu z tym importowanie danych / procesy ETL są prawie zawsze bardzo proste i proste. Ładuj dane tak często, jak potrzebujesz, miejsce jest tanie. Możesz uwzględnić skalowalność dla każdej aplikacji niezależnie, dostosowywać i poprawiać struktury według potrzeb i nie będzie problemów z współbieżnością. Efekty uboczne można również śledzić znacznie łatwiej.

Edycja: Chciałbym jednak zauważyć, że jak wspomniano w @Saeed, jeśli możesz obudować manipulacje danymi w usłudze, która jest powszechnie dostępna, łatwiej jest udostępnić jedną bazę danych wielu aplikacjom. Tak długo, jak nie potrzebujesz surowego dostępu, jest to bardzo dobre podejście.

Kiedyś miałem podobną sytuację. Moim problemem było zbudowanie 3 aplikacji, jednej do zarządzania zapasami, jednej do zarządzania zaopatrzeniem i jednej do zarządzania użytkownikami, tj. Pracownikami. Odradzam fizyczne łamanie baz danych dla aplikacji lub łączenie ich fizycznie dla aplikacji. Zamiast tego logiczna separacja IMHO działa lepiej.

Na przykład wszystkie 3 aplikacje musiały pracować z informacjami o pracownikach. Zarówno systemy zapasów, jak i zaopatrzenia korzystały z tych samych informacji o towarach i elementach magazynowych.

Stworzyłem wspólną bazę danych, w której zapisałem informacje o użytkownikach i towarach. Następnie zbudowałem na nim warstwę usług i korzystałem z tych usług w innych aplikacjach. Aby na przykład wyświetlić listę wszystkich pracowników, którzy są teraz w firmie, musiałem tylko wywołać metodę z usługi, takiej jak GetOnWorkEmployees().

Stworzyłem również wspólny interfejs do interakcji z użytkownikami i towarami, który był osobną aplikacją internetową.

Tak więc, dodając do tego, co wskazał @Falcon, myślę, że możesz skorzystać ze scentralizowania wspólnej funkcjonalności aplikacji w jednej bazie danych.

Jeśli te aplikacje mają działać z tych samych danych - na przykład z tej samej listy produktów i klientów - przechowuj bazę danych razem. Nic nie zyskujesz przez oddzielanie baz danych. To kwestia czysto „ludzka” - dla serwera to tylko bajty na dysku. Nie obchodzi go, czy ma 1 lub 100 baz danych. Ale jeśli go podzielisz, musisz poradzić sobie z synchronizacją danych. Problemy związane z indeksowaniem nie są prawdziwym problemem - spędziłbyś tyle samo czasu procesora na utrzymywaniu indeksów, gdyby bazy danych były podzielone.

Jeśli wydajność zaczyna być problemem, zreplikuj bazę danych na wielu serwerach, aby zrównoważyć sytuację.

W twojej sytuacji może być lub nie warto, ale utrzymanie integralności danych jest łatwiejsze dzięki jednej bazie danych. Przynajmniej w MS SQL Server nie można obcy klucz z jednej bazy danych do innej bazy danych. Można symulować zachowanie klucza obcego za pomocą wyzwalaczy, ale nie jest to szczególnie eleganckie.

Ponadto tworzenie lokalnych kopii danych może być niebezpieczne, gdy zaczną się zapisy. Jeśli zarówno AppA, jak i AppB mają kopię niektórych wspólnych danych, a AppA je zaktualizuje, AppB nadal będzie mieć stare dane. Lub będziesz musiał skonfigurować wyzwalacze, aby zachować synchronizację danych.

Kiedyś miałem wiele stron internetowych, które z czasem stały się popularne. Używali osobnych baz danych, głównie dlatego, że dostawca hostingu zezwalał tylko na 1 GB przestrzeni dyskowej. Ale! Gdy tylko wydałem usługę obejmującą wszystkie te strony, zacząłem robić transakcje między tymi stronami, a najwygodniejszym sposobem na to jest zdecydowanie przeniesienie wszystkiego do jednej dużej bazy danych.

Zoptymalizowałem więc strukturę bazy danych i wycisnąłem odpowiednie części do tej centralnej bazy danych, ale zostawiłem wszystko inne.

Moja opinia jest w jakiś sposób związana z paradygmatami OOP. Podobne dane muszą być przechowywane razem, więc jeśli budujesz różne aplikacje, powinieneś używać dla nich różnych baz danych.

W powyższym przypadku nie można było uniknąć używania wspólnej bazy danych, ale należy pamiętać, że niektóre tabele trzymałem oddzielnie w osobnej bazie danych, które nie są częścią typowych zapytań.

Co więcej, jeśli będziesz je rozdzielać, łatwiej będzie tworzyć kopie zapasowe, a ryzyko utraty danych będzie mniejsze. Jeśli coś pójdzie nie tak i aplikacje będą ze sobą kolidować, baza danych zostanie pomieszana i zasadniczo nie chcesz narażać aplikacji na to niebezpieczeństwo.

Podsumowując, możesz utrzymywać wspólną bazę danych dla typowych zapytań, ale także zachować jedną dla każdej aplikacji.

Czy możesz rozwinąć swoją architekturę aplikacji?

Jeśli baza danych działa jak repozytorium danych bez logiki aplikacji, takiej jak wyzwalacze lub kod pakietu biznesowego, lepiej byłoby mieć jedną bazę danych i obudować funkcjonalność na poziomie biznesowym usługom, które wykorzystują bazę danych do wszystkich swoich działań. Jeśli masz wyzwalacze lub kod w schemacie bazy danych, będziesz miał poważne kłopoty, korzystając z jednej bazy danych, co może być kłopotliwe w wielu przypadkach.