[Microsoft SQLServer 2008] Indici SPAZIALI

[Andrea Simonassi]

Vorrei sapere, se possibile, quale è il modo di creare indici spaziali (parliamo di tipo dato geometry e non geography) per velocizzare al massimo le query?

Il database geografico viene aggiornato spot ogni N mesi e quindi la velocità nelle insert non è per nulla un problema.

Inoltre quale è la funzione che da le migliori prestazioni per quanto riguarda la JOIN tra due tabelle volendo avere come risultato i record in cui un l'area in una tabella ha almeno un punto in comune con l'area nell'altra?

Attualmente uso una cosa del genere, lentissima:

SELECT  
	NAZIONI.ISO3,   
	gisLocations.location_id, 
	gisLocations.location_name
FROM    
		gisLocations 
	INNER JOIN
                dbo.NAZIONI ON gisLocations.geom_circle_500m.STIntersects (NAZIONI.geom) = 1

Noto che Postgres ha una velocità di esecuzione terribilmente superiore rispetto SQL Server per quel che riguarda dati geografici, (una cosa nell'ordine del 100 a 1) nonostante attualmente sia installato su hardware nettamente inferiore.

E' una cosa risaputa per cui non resta da fare che progettare migrazioni in massa su Postgres oppure è semplicemente che in SQL SERVER ci sono altri modi per ottimizzare le query?

Nel caso esiste la possibilità di linkare il server postgres al server sql 2008 (so windows 2008 server 64 bit) ?

Ciao a tutti

[Andrea Simonassi]

Belin ragazzi, 1 ora e 18 minuti e ancora non ha completato la seguente, soltanto gli dei sanno quando completerà l'esecuzione:

update gisLocations set iso3= NAZIONI.ISO3
FROM         gisLocations WITH (INDEX (Spatial_gislocations))
 CROSS JOIN
                      dbo.NAZIONI WITH(INDEX(SPATIAL_GisAreas))
                      
                      where gisLocations.geom.STIntersects (NAZIONI.geom) = 1

300K righe circa per ogni tabella. La vista NAZIONI sulla tabelle GisAreas restituisce solo 300 records, mi pare che le prestazioni siano veramente da panico.

Per altro se non metto le clausole WITH (INDEX ..) l'amico SQL SERVER ignora completamente gli indici spaziali.

Il monitor mi dice che la CPU del server è a cazzeggio, e i dischi non sono manco poi così impiccati, considerato che a quest'ora c'è pausa pranzo.

ISO3 , che sto aggiornando , è in effetti un campo indicizzato, però è un campo di tipo char(3) .. dico che non è la modifica di quell'indice che sta facendo morire il server...

[optime]

da come esponi il problema sembra che se SQL tratta dati geometrici/geaografici diventa una tartaruga, mentre invece si comporta normalmente se tratta dati di magazzino... è così?

[Andrea Simonassi]

Non so cosa rispondere, per quanto riguarda gli indici "NON spaziali" penso che funzioni abbastanza bene.

Anche se a volte fa un po girare le scatole, soprattutto quando compili una query con parametro l'ottimizzatore non funziona a dovere. (OFFTOPIC) per fare un esempio una query come la seguente con filtro su un dato di tipo NVARCHAR

select questo from <marea di tabelle con vari joins> where questo.dato=@dato

potrebbe eseguire in 16 minuti (storia vera non musse) mentre

exec ('select questo from <marea di tabelle con vari joins> where questo.dato=N''dato''')

esegue in 3 secondi.... detto questo, se io fossi il progettista microsoft e il piano di esecuzione della query parametrizzata avesse un costo esagerato proverei a ricompilare la query con il valore attuale del parametro e infine sceglierei il piano di esecuzione col costo minore.

(/OFFTOPIC)

Ad ogni modo la query di cui in oggetto al post, dopo 4 ore e 40 minuti l'ho uccisa. Cercherò di spezzare il problema in sotto problemi (ad esempio lanciare 10000 query una per ogni area amministrativa in cui sono suddivise le varie nazioni)