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

[Ivano]

Io penso che lo sviluppo lato client sia stato un "retaggio storico".
Con gli attuali DBMS è senz'altro più semplice appoggiarsi alle
funzioni presenti, per non parlare poi di tutte le funzioni "composte"
che possono essere realizzata se si introducono i concetti di
topologia, network, segmetnazione dinamica, etc etc.


>
> 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.

Si, per non parlare delle procedure ottimizzate sulla base di indici,
l'esistenza di meccanismi per l'ottimizzazione del plan di una query,
la gestione della memoria e del file system, etc etc.

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

Non è da escludere affatto, anzi: è proprio così! Pensa poi se
parliamo a livello regionale!

>
> 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 ....)

Risoluzione automatica che adesso è anch'essa disponibile come
prodotti di terze parti per alcuni DBMS (Oracle in primis).

>
> Saluti,
>
>
> Il 20 novembre 2008 12.33, G. Allegri <giohappy a 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 a 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 a 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                 §
> ~~~~~~~~~~~~~~~~~
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> Gfoss a 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.
>