[Gfoss] Sun compra MySQL

[Andrea Peri]

Fare le analisi spaziali con l' MBR non e' prerogativa di MySQL.
Tutti i DB che possiedono un modulo spaziale operano
sempre in due passi, prima isolano l'intorno con l' MBR e poi
raffinano con altri algoritmi piu' precisi.

E di conseguenza forniscono due gruppi di funzioni, un gruppo lavoro a
livello MBR , ovvero svolge solo il primo passo. Il secondo gruppo di
funzioni opera a livello di massima precisione e quindi opera con 2
passi.

Per cui la mia perplessita' non era tanto rivolta al fatto che vi
fossero delle funzioni che operassero a livello di MBR, ma piuttosto
rivolta al fatto che non vi fossero funzioni per il secondo gruppo.

Cosa che a una lettura superficiale della documentazione di MySQL non traspare,

perche' MySQL e' impostato esattamente come gli altri DB, ovvero due
gruppi di funzioni.

Infatti ha le funzioni del primo gruppo, quelle che operano sull'MBR,
http://dev.mysql.com/doc/refman/6.0/en/relations-on-geometry-mbr.html
come ad esempio:
-) MBRContains(g1,g2)
-) MBRIntersects(g1,g2)
etc...

e poi ha le funzioni del secondo gruppo, che dovrebbero raffinare il risultato:
http://dev.mysql.com/doc/refman/6.0/en/functions-that-test-spatial-relationships-between-geometries.html
come ad esempio:
-) Contains(g1,g2)
-) Intersects(g1,g2)
etc..

solo che quest'ultime restituiscono il medesimo risultato di quelle
del primo gruppo.

Intendiamoci, pero'.
Non sto' dicendo che sono disonesti. Tutt'altro.
Perche' nella pagina la cosa e' ben chiarita, e scritta nelle prime righe.
Per cui chi si spende a leggere la documentazione lo scopre subito,
chi si affida al solito manualetto rapido, non lo sa' e sono fatti
sua.

Si capisce anche il perche' di questo sdoppiamento. Perche' cosi' chi
vuole un risultato esatto, scrive il codice usando le funzioni del
secondo gruppo. Se poi il risultato non va bene, pazienza, aggiunge
lui le routines per raffinarlo (come appunto dici te).
Poi un domani che MySQL migliorera' le cose (chissa quando), bastera'
buttar via il codice di raffinamento scritto a mano e affidarsi
direttamente a tali funzioni.
Niente da eccepire, tutto giusto e corretto.
E' senzaltro un approccio rivolto agli sviluppatori, se non vi fossero
state le funzioni del secondo gruppo, un domani che fossero state
aggiunte, si sarebbe dovuto rimettere mano pesantemente al codice e
questo e' sempre da evitare se possibile.

Il punto e' ad oggi MySQL offre un set inferiore (dal punto di vista
dell'analisi spaziale) rispetto ad altre soluzioni.
E francamente mi secca un po' quando nei discorsi sento interloquire
persone che sostengono quanto sia ricco , completo e velocissimo il
modulo spaziale di MySQL.

E' chiaro che si tratta di affermazioni che non tengono conto di
quello che sono i risultati che effettivamente vengono fuori, e che
risentono di una analisi forse troppo frettolosa e basata solo sul
conteggio di quante funzioni sono enucleate nella documentazione.

E' altresi' evidente che nel tuo caso, le necessita' di analisi
spaziale erano ridotte e quindi quello che faceva MySQL era
sufficiente.
Tante' che se pure avessi avuto postgres a disposizione probabilmente
non avresti usato le sue funzioni del secondo gruppo, ma ti saresti
comunque limitato a usare quelle di analisi a livello di MBR, per
avere la max. velocita.

Quindi e' un esempio di situazione in cui va bene anche usare MySQL.

Pero' spesso si sentono discorsi dove si generalizza.
Quanto e' veloce mysql nell'analisi spaziale....
quante funzioni ha mysql nell'analisi spaziale....
e cosi' via.
Tutte cose che poi nella realta' non sono verificate.

Andrea.



2008/1/17, a.furieri at lqt.it <a.furieri at lqt.it>:
> On Thu, 17 Jan 2008 19:20:49 +0100, Diego Guidi wrote
> > > Il che significa che al momento tutte queste funzioni.anziche' agire
> > > sull'area esatta della geometria (se poligonale) agiscono sul
> > > rettangolo di ingombro.
> > Te lo confermo perchè tempo fa andai a guardare il codice e rimasi a
> > bocca aperta...
> > come dire "era meglio che non ci mettevamo niente, almeno non stavamo
> > a vendere aria fritta..."
>
> Bicchiere mezzo pieno oppure bicchiere mezzo vuoto ?
> Spesso è questione di gusti ... e di requisiti funzionali ...
>
> MySQL non pretende affatto di supportare a fondo la
> spatial analysis, e lo riconosce molto chiaramente
> ed onestamente in tutta quanta la documentazione
>
> Ma se lo scopo è semplicemente quello di supportare un
> web server [e scusate del poco ...], allora basta ed
> avanza un'indicizzazione spaziale che operi sui rettangoli
>
> Mi spiego meglio; se devo generare una mappa che
> rappresenta una manciata di isolati nel centro di
> Firenze, mi basta abbondantemente un indice
> che recuperi "di corsa" quella decina di assi
> strada, edifici, fermate bus etc etc che mi interessano,
> scartando le altre centomila entità che ora non mi servono;
> se anche la query [usando il "rozzo" criterio dei rettangoli]
> ritorna qualche decina di entità che non appartengono alla
> mappa in elaborazione, non è poi una tragedia, no ?
> Ci penserà il sw di rasterizzazione a scartarle; ma intanto
> l'indice spatial di MySQL mi serve efficacemente per eseguire
> una query molto veloce
>
> ciao Sandro Furieri
>


-- 
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~