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

[G. Allegri]

Se dunque la soluzione client è un collo di bottiglia, quella basata
su procedure nel DB vincola ad un determinato RDBMS... La soluzione
sarebbe su server? Bhe, un bel workload!

Il 20 novembre 2008 17.58, Ivano <ivano.picco a gmail.com> ha scritto:
> 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.
>>
>