Mieszanie typów geometrii w jednej tabeli PostGIS

Mam do czynienia z następującym problemem. Muszę przeprowadzić migrację z bazy danych Oracle do PostgreSQL + PostGIS. Obecnie wszystkie geometrie wszystkich typów są przechowywane w jednej tabeli, a każdy rekord zawiera pole „lid”, które wskazuje cechy tej samej warstwy.

Jakie są zalety i wady korzystania z takiej metody? Czy należy podzielić dane na wiele tabel, jeśli nie muszę korzystać z bazy danych z oprogramowaniem innych firm? Co z wydajnością zapytań przestrzennych, czy indeksy mi pomogą?

Jeśli nie potrzebujesz pomocy strony trzeciej i nie widzisz potrzeby zapytania według typu, utrzymanie ich w tej samej tabeli działa dobrze. Alternatywnie możesz użyć modelu dziedziczenia, jak omówiono w rozdziale 3 PostGIS w działaniu.

http://www.postgis.us/chapter_03_edition_1

Z perspektywy architektury PostGIS tak naprawdę nie obchodzi, czy w zapytaniu używanych jest wiele różnych typów. Jeśli dobrze działało to w Oracle, będzie tak samo, jakby nie lepiej działało w PostGIS.

Istnieją dwa powody, aby go podzielić (i jedno lub drugie można zrobić później, w razie potrzeby): 1) Zapobiegaj wstawianiu różnych typów, których nie chcesz, takich jak kolekcje geometrii, ciągi kołowe i co nie (co możesz po prostu ręcznie zdefiniować ograniczenie )

2) Jeśli masz miliard punktów i 1000 wielokątów i wykonujesz wiele punktów w testach wielokątów, prędkość jest znacznie lepsza, jeśli zapytasz i wykonasz połączenie - w porównaniu z miliardem - do 1000 rekordów w przeciwieństwie do tabela rekordów od miliarda do miliarda. Tak byłoby w przypadku każdej bazy danych przestrzennych (nie dotyczy PostGIS). Odnosi się to również do wszystkich zapytań relacyjnych (niespecyficznych dla zapytań przestrzennych).

Ten naprawdę mnie niepokoi. Chyba dlatego, że widziałem zbyt wiele plików CAD z danymi na jednej warstwie, zróżnicowanymi tylko kolorem.

Sprowadza się to do wyboru między uporządkowaniem danych według struktury lub według atrybutu .

Biorąc pod uwagę ten wybór, zawsze chciałbym organizować swoje dane według struktury danych.

Na początek, podczas przetwarzania danych, masz o jedną mniejszą obręcz do przeskoczenia (np. Wybierz a, b, c z tabeli, gdzie id = X, a nie wybierz a, b, c z tabeli, gdzie id = X AND pokrywa = Y )

Następnie zastanów się, dlaczego bazy danych zezwalają na wiele tabel - jeśli format danych oferuje określone struktury danych, musisz pomyśleć, że będą przetwarzać dane bardziej wydajnie, jeśli ich użyjesz.

Ale dużym problemem (dla mnie) jest to, kiedy chcesz przenieść dane do innego systemu. Myślę, że staje się to prawdziwym wyzwaniem, ponieważ aplikacja końcowa może nie wykorzystywać danych w ten sam sposób. Widziałem, jak wiele osób utknęło w tym scenariuszu.

Tak więc - z mojego doświadczenia - będziesz w stanie wykorzystywać i przesyłać dane dwa razy wydajniej, jeśli ma przyzwoity (głębszy i bardziej uporządkowany) model danych.