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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: >>>>> 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 >>>> [email protected] >>>> 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 >> [email protected] >> 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. >> > _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] 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.
