Po tym komentarzu do jednego z moich pytań zastanawiam się, czy lepiej jest używać jednej bazy danych ze schematami X, czy odwrotnie.
Moja sytuacja: tworzę aplikację internetową, w której podczas rejestracji tworzę (właściwie) bazę danych (nie, to nie jest sieć społecznościowa: każdy musi mieć dostęp do swoich danych i nigdy nie widzieć danych innego użytkownika) .
W ten sposób korzystałem z poprzedniej wersji mojej aplikacji (która nadal działa na MySQL): za pośrednictwem Plesk API, przy każdej rejestracji wykonuję:
- Utwórz użytkownika bazy danych z ograniczonymi uprawnieniami;
- Utwórz bazę danych, do której będzie miał dostęp tylko poprzednio utworzony użytkownik i superużytkownik (w celu konserwacji)
- Wypełnij bazę danych
Teraz muszę zrobić to samo z PostgreSQL (projekt dojrzewa, a MySQL ... nie spełnia wszystkich potrzeb).
Muszę mieć niezależne kopie zapasowe wszystkich baz danych / schematów: pg_dump działa doskonale w obie strony i to samo dla użytkowników, których można skonfigurować tak, aby mieli dostęp tylko do jednego schematu lub jednej bazy danych.
Więc zakładając, że jesteś bardziej doświadczonymi użytkownikami PostgreSQL niż ja, jakie myślisz, że jest najlepsze rozwiązanie w mojej sytuacji i dlaczego?
Czy wystąpią różnice w wydajności przy korzystaniu z bazy danych $ x zamiast schematów $ x? A jakie rozwiązanie będzie lepsze w przyszłości (niezawodność)?
Wszystkie moje bazy danych / schematy będą zawsze miały tę samą strukturę!
W przypadku tworzenia kopii zapasowych (przy użyciu pg_dump), może lepiej jest użyć jednej bazy danych i wielu schematów, zrzucenie wszystkich schematów naraz: odzyskiwanie będzie dość proste, załadowanie głównego zrzutu na maszynę programistyczną, a następnie zrzucenie i przywrócenie tylko potrzebnego schematu: tam to jeden dodatkowy krok, ale zrzucanie wszystkich schematów wydaje się szybsze niż zrzucanie ich jeden po drugim.
UPDATE 2012
Cóż, struktura i projekt aplikacji bardzo się zmieniły w ciągu ostatnich dwóch lat. Nadal stosuję to one db with many schemas
podejście, ale nadal mam jedną bazę danych dla każdej wersji mojej aplikacji:
Db myapp_01
\_ my_customer_foo_schema
\_ my_customer_bar_schema
Db myapp_02
\_ my_customer_foo_schema
\_ my_customer_bar_schema
W przypadku kopii zapasowych regularnie zrzucam każdą bazę danych, a następnie przenoszę kopie zapasowe na serwer deweloperski.
Używam też kopii zapasowej PITR / WAL, ale jak powiedziałem wcześniej, nie jest prawdopodobne, że będę musiał przywracać całą bazę danych naraz ... więc prawdopodobnie zostanie odrzucona w tym roku (w mojej sytuacji nie jest to najlepsze podejście ).
Podejście jeden-db-wiele-schematów działało bardzo dobrze od teraz, nawet jeśli struktura aplikacji została całkowicie zmieniona:
Prawie zapomniałem: wszystkie moje bazy danych / schematy będą zawsze miały tę samą strukturę!
... teraz każdy schemat ma własną strukturę, która zmienia się dynamicznie w odpowiedzi na przepływ danych użytkowników.