[Gfoss] [OT] Re: R: editazione multiutente nei database enterprise

Andrea Peri peri.rtoscana a gmail.com
Gio 20 Nov 2008 14:59:55 CET


> Riguardo il secondo punto, condivido quanto dice Diego sulla necessità
> di essere svincolati dal db, percui i sistemi di validazione non
> dovrebbero essere basati su procedure db-side. Personalmente condivido
> l'architettura Esri: ArcSDE "fornisce" il modello (mantenuto in
> qualche forma nel DB), il client [1] si occupa di validare. La stessa
> cosa la vedrei anche per la gestione del versioning. Adesso Geoserver
> offre un modulo (WFSV) per un Postgis configurato ad-hoc... L'optimum
> sarebbe riuscire a gestirlo ad un livello di astrazione maggiore.

Concorderei anche io che non ha senso riscriversi un client che faccia
quello che gia' fa' ArcGIS.
La discussione era filosofica.
Infatti se se uno "vuole" e "puole" lo potrebbe fare.
Diverse e' dire non e' possibile farlo.

Comunque per passare alla seconda parte del discorso,

Io non penso che convenga farla lato client.
E' piu' semplice da sviluppare senz'altro.
Ma poi lo paghi in efficienza.

Infatti quando dicevo magnanimamente che era un "pochino lento" , e
Diego ha puntualizzato con un "mostruosamente.."

Va chiarito che la causa di tale lentezza e' da ricercarsi
principalmente nella scelta tecnologica di fare la validita' a livello
di client, e non come si potrebbe pensare perche' sono poco esperti i
programmatori esri, che anzi sembrano dei molto capaci.

infatti lavorando al ivello client non puoi usare tutti gli strumenti
che il DBMS ti mette a disposizione (trigger e stored-procedure) e per
giunta sei costretto anche a operare proceduralmente per tenere la
compatibilita' con tutti i vari DBMS.
Tutto questo penalizza molto la velocita' di esecuzione.

Infatti se si lavora a livello client ci si scontra inevitabilmente
con dei colli di bottiglia invalicabili.
La rete, il caricamento delle features sul client prima che possa
cominciare a eseguire le varie intersezioni spaziali, overlaps, e
quant'altro gli serve per validare la feature.

Per questo il sistema ESRI e' pensato tipicamente per l'editing "minuto"
Cioe' per l'inserimento di una singola feature.

Mi spiego meglio .
Se hai un sistema e vai a inserirci una singola feature, ad esempio un pozzo.
Poi lo puoi validare, la validazione sara' un qualcosa che richiede
pochi secondi, massimo 1 minutino.

Pero', per lavorare cosi' devi sempre avere il client ArcGIS in
contatto con l' ArcSDE.

E quindi se pensi di sviluppare il lavoro affidandolo a un soggetto
esterno per poi validarne l'operato quando ti ritorna i risultati....
E supponi che il risultato sia una intera provincia.

Non e' da escludere che l'esecuzione della validazione se tutto va
bene, possa richiedere anche qualche giorno di esecuzione.

Come sottoprodotto della logica di validazione poi vi e' anche il
problema che non ha senso elencare tutte le features non valide.
Ma occorre svilupparla sequenzialmente.
Per cui se ad esempio nel tuo archivio sono 4 feature non valide.

Alla prima feature non valida il sistema si ferma segnalandotela.
E finche' non la hai rimessa a posto lui non passa oltre per elencarti
le successive.

ma questo e' una conseguenza della logica operativa e non della scelta
della validazione sul client.
Per superarla occorrerebbe implementare non solo la validazione, ma
anche la risoluzione automatica del problema, ovvero il sistema
corregge automaticamente ....
( un altro film ....)

Saluti,


Il 20 novembre 2008 12.33, G. Allegri <giohappy at gmail.com> ha scritto:
> in sintesi, mi sembra che siano sorte 2 questioni principali:
>
>  1 - come/se offrire strumenti per permettere a client desktop OS di
> gestire e accedere alle funzionalità offerte da ArcSDE
>  2 - sviluppare alternative ad ArcSDE
>
> Premetto: scusate se scriverò castronerie! :) Parlo più da un punto di
> vista dell'utente che non da sviluppatore enterprise!
>
> Pur comprendendo l'importanza dell'interoperabilità e
> dell'integrazione, sinceramente ritengo prioritario il secondo. Non mi
> sembra il caso di spendere le poche o tante risorse a disposizione per
> riprodurre ciò che ArcGIS fa rispetto ad ArcSDE, altrimenti si finisce
> per incatenarci a quest'ultimo. Lo dico perché delle volte è emersa
> questa direzione...
>
> Riguardo il secondo punto, condivido quanto dice Diego sulla necessità
> di essere svincolati dal db, percui i sistemi di validazione non
> dovrebbero essere basati su procedure db-side. Personalmente condivido
> l'architettura Esri: ArcSDE "fornisce" il modello (mantenuto in
> qualche forma nel DB), il client [1] si occupa di validare. La stessa
> cosa la vedrei anche per la gestione del versioning. Adesso Geoserver
> offre un modulo (WFSV) per un Postgis configurato ad-hoc... L'optimum
> sarebbe riuscire a gestirlo ad un livello di astrazione maggiore.
>
> [1] Nel fantastico mondo dei sogni, io mi immagino una sorta di
> libreria/plugin dedicata a questo, da poter "wrappare" nei diversi
> client.
>
> Avrò detto molte banalità. E' solo per condividere un po' delle
> richieste che via via mi vengono fatte sul tema...
>
> 2008/11/20 Diego Guidi <diegoguidi at gmail.com>:
>>> Il sorgente è a disposizione, per quanto ne posso capire basta
>>> implementare il support per queste look up table.
>>> Non vedo un problema strutturale, solo la mancanza di qualcuno
>>> che abbia insieme la capacità e l'interesse per realizzare questa
>>> funzione.
>>
>> Giustissimo
>> _______________________________________________
>> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
>> Gfoss at faunalia.com
>> http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non rispecchiano necessariamente
>> le posizioni dell'Associazione GFOSS.it.
>>
>



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


Maggiori informazioni sulla lista Gfoss