Używasz schematu innego niż publiczny w PostGIS?

Obecnie konfiguruję nową instalację PostGIS 2.0.2 i PostgreSQL 9.1.6 na Ubuntu. Ostatnio natknąłem się na pewne informacje wskazujące, że używanie publicznego schematu do przechowywania wszystkich danych nie jest dobrym pomysłem.

Z tego powodu utworzyłem schemat o nazwie dane i zostałem właścicielem, ale czy to dobry pomysł?

Moje obawy to:

1. Oprócz ustawienia właściciela, może być konieczne zwrócenie uwagi na rzeczy na karcie Uprawnienia podczas tworzenia tego nowego schematu (poprzez pgAdmin III);
2. Nie mogę uzyskać takich samych korzyści, przechowując moje dane w schemacie publicznym i zrzucając wszystkie dane do osobnego schematu przed utworzeniem kopii zapasowej / przywracania (zaoszczędziłoby to kilka naciśnięć klawiszy podczas korzystania z ogr2ogr); i
3. Mogę wpaść w kłopoty, ponieważ nie mam domyślnych tabel i widoków PostGIS w moim nowym schemacie danych (są one w schemacie publicznym w tej samej bazie danych).

Jest to teraz rozwiązane na oficjalnej stronie na stronie zatytułowanej Przenieś rozszerzenie PostGIS do innego schematu . Poprawną metodą jest zainstalowanie rozszerzenia public. To jedyna opcja. Rozszerzenie nie obsługuje już relokacji. Następną rzeczą jest uruchomienie następujących poleceń (skopiowanych z witryny),

UPDATE pg_extension 
  SET extrelocatable = TRUE 
    WHERE extname = 'postgis';

ALTER EXTENSION postgis 
  SET SCHEMA postgis;

Po włączeniu przestrzennym bazy danych PostGIS odpowiednie funkcje, tabela SRS i widoki są umieszczane w schemacie publicznym, jak sam twierdzisz. Nie oznacza to, że wszystkie lub dowolne z twoich tabel przestrzennych muszą znajdować się w tym samym schemacie publicznym. PostGIS nadal będzie działał na wszystkich danych przestrzennych w „nowych” schematach.

W rzeczywistości zazwyczaj umieszczam tabele specyficzne dla aplikacji w osobnym schemacie. W ten sposób, jeśli musisz dokonać aktualizacji głównej wersji do PostGIS, możesz zachować kopie zapasowe tabel specyficzne dla aplikacji i przywracać je jako oddzielną procedurę niż ta, która zastępuje narzędzia przestrzenne.

Więc myślę, że masz się dobrze. Na koniec, jeśli jeszcze tego nie zrobiłeś, dobrym pomysłem jest dodanie nowego schematu do ścieżki wyszukiwania:

ALTER DATABASE my_db SET search_path = gc, public;

1. Jedną z możliwych strategii organizacyjnych, które można zbudować za pomocą schematów, jest umożliwienie użytkownikowi uruchomienia szalejącego w jednym schemacie, ale niemożności zepsucia się w innym. Jeśli więc chcesz używać schematów w ten sposób, możesz to zrobić na karcie uprawnień w pgAdmin. Ale nie jest to wymagane, więc jeśli chcesz zachować te same uprawnienia w wielu schematach, to dobrze.

2. W oparciu o artykuły, z którymi się łączysz, problem z utrzymywaniem wszystkiego w miejscu publicznym polega na tym, że kiedy zrzucisz dane, prawdopodobnie zmieszasz tabele systemowe i relacje z danymi. Jeśli przeniesiesz wszystkie dane do nowego schematu, nie musisz się o to więcej martwić.

3. Żaden problem. (Na dowód zauważ, że nie musisz określać public.spatial_ref_sys, jeśli chcesz przeszukać tabelę SRS.)

Jedna dodatkowa wskazówka (może już to natrafiłeś). Prawdopodobnie będziesz chciał dodać schemat „danych” do domyślnej ścieżki wyszukiwania użytkownika. Coś jak:

ALTER USER <your_user_name> SET search_path=public,data,$USER; 

Jeśli chodzi o punkt 2, czasami musisz przywrócić, gdy nie masz już dostępu do oryginalnej bazy danych. (To jeden z powodów tworzenia kopii zapasowych ...), więc możesz nie mieć szansy na przeniesienie danych do osobnego schematu, kiedy naprawdę go potrzebujesz.

Używamy publicznego schematu do tymczasowej analizy / wyników tabeli deweloperów, a następnie przechodzimy do bardziej zorganizowanych schematów (folderów?) Do stałego użytku.