Miscelazione di tipi di geometria in una tabella PostGIS

Sono di fronte al seguente problema. Devo migrare dal database Oracle a PostgreSQL + PostGIS. Attualmente tutte le geometrie di tutti i tipi sono memorizzate in una tabella e ogni record contiene un campo "coperchio" che indica le caratteristiche dello stesso livello.

Quali sono i pro e i contro dell'utilizzo di tale metodo? Devo suddividere i dati in più tabelle se non ho bisogno di utilizzare il database con software di terze parti? Che dire delle prestazioni delle query spaziali, gli indici mi aiuteranno?

Se non hai bisogno di supporto di terze parti e non prevedi la necessità di eseguire una query per tipo, mantenendoli nella stessa tabella funziona perfettamente. In alternativa, è possibile utilizzare un modello di ereditarietà come discusso nel capitolo 3 di PostGIS in azione.

http://www.postgis.us/chapter_03_edition_1

Dal punto di vista dell'architettura PostGIS non si preoccupa davvero se in una query vengono utilizzati più tipi diversi. Se ha funzionato bene per te in Oracle, sarà proprio come se non avesse prestazioni migliori in PostGIS.

Ci sono 2 motivi per dividerlo (e uno può essere fatto in seguito, se necessario): 1) Impedire alle persone di inserire tipi diversi che non si desidera come raccolte di geometrie, stringhe circolari e cosa no (che è possibile definire manualmente un vincolo )

2) Se hai un miliardo di punti e 1000 poligoni e fai molto punto nei test poligonali, la velocità è molto migliore se quando esegui una query e fai il tuo join - è contro un miliardo - a 1000 record table invece di tavolo da un miliardo a miliardi di record. Questo sarebbe il caso di qualsiasi database spaziale che penso (non specifico di PostGIS). È vero per tutte le query relazionali che immagino anch'io (non specifico per le query spaziali).

Questo mi preoccupa davvero. Immagino sia perché ho visto troppi file CAD con dati tutti su un livello, differenziati solo per colore.

Ciò a cui si riduce è davvero una scelta tra l'organizzazione dei dati per struttura o per attributo .

Data questa scelta, vorrei sempre organizzare i miei dati attraverso la struttura dei dati.

Per cominciare, durante l'elaborazione dei dati hai un telaio in meno da saltare (ad esempio, seleziona a, b, c dalla tabella dove id = X invece di selezionare a, b, c dalla tabella dove id = X AND lid = Y )

Quindi, considera perché i database consentono più tabelle: se un formato di dati offre particolari strutture di dati, devi pensare che elaboreranno i dati in modo più efficiente se li utilizzi.

Ma il grosso problema (per me) è quando si desidera spostare i dati in un altro sistema. Quindi penso che diventi una vera sfida, perché l'applicazione finale potrebbe non utilizzare i dati allo stesso modo. Ho visto così tante persone che si sono sbloccate in questo scenario.

Quindi, secondo la mia esperienza, sarai in grado di utilizzare e trasferire i dati due volte in modo più efficiente quando ha un modello di dati decente (più profondo e più strutturato).