Geometrietypen in einer PostGIS-Tabelle mischen

Ich stehe vor dem folgenden Problem. Ich muss von der Oracle-Datenbank auf PostgreSQL + PostGIS migrieren. Gegenwärtig werden alle Geometrien aller Typen in einer Tabelle gespeichert und jeder Datensatz enthält ein "Deckel" -Feld, das Merkmale derselben Ebene anzeigt.

Was sind die Vor- und Nachteile einer solchen Methode? Sollte ich Daten in mehrere Tabellen aufteilen, wenn ich die Datenbank nicht mit Software von Drittanbietern verwenden muss? Was ist mit der Leistung von räumlichen Abfragen? Helfen mir die Indizes?

Wenn Sie keinen Support von Drittanbietern benötigen und die Notwendigkeit, nach Typ abzufragen, nicht übersehen, funktioniert dies einwandfrei. Alternativ können Sie ein Vererbungsmodell verwenden, wie in Kapitel 3 von PostGIS in Action beschrieben.

http://www.postgis.us/chapter_03_edition_1

Aus Sicht der Architektur ist es PostGIS eigentlich egal, ob in einer Abfrage mehrere verschiedene Typen verwendet werden. Wenn es für Sie in Oracle gut funktioniert hat, ist es in PostGIS genauso gut, als wäre es nicht besser.

Es gibt zwei Gründe für die Aufteilung (und beides kann nach Bedarf später erfolgen): 1) Verhindern Sie, dass Personen andere Typen einfügen, die Sie nicht möchten, z. B. Geometriesammlungen, kreisförmige Zeichenfolgen und was nicht (die Sie einfach manuell definieren können) )

2) Wenn Sie eine Milliarde Punkte und 1000 Polygone haben und viele Punkte in Polygontests machen, ist die Geschwindigkeit viel besser, wenn Sie abfragen und Ihre Verknüpfung - im Gegensatz zu einer Milliarde - zu 1000 Datensatztabellen durchführen eine milliarden zu milliarden rekordtabelle. Dies ist meiner Meinung nach für jede räumliche Datenbank der Fall (nicht spezifisch für PostGIS). Dies gilt auch für alle relationalen Abfragen (nicht spezifisch für räumliche Abfragen).

Dieser stört mich wirklich. Ich denke, das liegt daran, dass ich zu viele CAD-Dateien mit Daten auf einer Ebene gesehen habe, die sich nur durch die Farbe unterscheiden.

Worauf es ankommt, ist wirklich die Wahl, die Daten nach Struktur oder Attributen zu organisieren .

Bei dieser Auswahl würde ich immer versuchen, meine Daten über die Datenstruktur zu organisieren.

Wenn Sie Daten verarbeiten, müssen Sie zunächst einen Rahmen weniger überspringen (z. B. a, b, c aus der Tabelle mit id = X und a, b, c aus der Tabelle mit id = X UND deckel = Y ).

Überlegen Sie sich dann, warum Datenbanken mehrere Tabellen zulassen. Wenn ein Datenformat bestimmte Datenstrukturen bietet, müssen Sie davon ausgehen, dass sie Daten effizienter verarbeiten, wenn Sie sie verwenden.

Aber das große Problem (für mich) ist, wenn Sie die Daten aus und in ein anderes System verschieben möchten. Dann denke ich, wird es eine echte Herausforderung, weil die Endanwendung Daten möglicherweise nicht auf die gleiche Weise verwendet. Ich habe so viele Leute gesehen, die in diesem Szenario hängen geblieben sind.

Nach meiner Erfahrung können Sie Daten also doppelt so effizient verwenden und übertragen, wenn sie ein anständiges (tieferes und strukturierteres) Datenmodell aufweisen.