consigli su stoccaggio dati‏

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

consigli su stoccaggio dati‏

Andrea Peri
>Ciao a tutti,chiederei consigli e opinioni riguardanti sistemi e sw da utilizzare per l'archiviazione, catalogazione e condivisione dati geografici e non ovviamente di tipo opensource.Sembra facile, ma non lo è, perchè chi ha accesso a questa condivisione dati ha le proprie abitudini e pretese in quanto a modalità di organizzazione, accesso, usabilità, ecc...Fissiamo dei punti:i dati sono digitali di ogni tipo, dai documenti doc, xls, ppt, pdf, jpg a quelli di tipo geografici localizzati e non di tipo raster e geografici vettoriali per lo più di tipo shp o ascii.I dati al momento da 'organizzare sono qualcosa come 1 Tb , con una velocità di espansione non elevatissima, diciamo circa 100 Gb anno??boh?forse è quasi troppo...
>Nel gruppo di lavoro c' è chi mi chiede una sorta di directory condivisa, con una organizzazione precisa delle sottodirectory, un modo insomma perchè tutti abbastanza 'amichevolmente' abbiano accesso alle varie directory....Questo secondo me crea il CAOS...quanto meno a lungo termine, senza considerare che dopo un pò di tempo ci si dimentica cosa viene stoccato chi l'ha stoccato,creando duplicati e versioni varie. A questo si aggiungono ovvi problemi di ricerca file.
>Sarebbe auspicabile un sistema catalogato, quindi organizzazione dati che passa da una metadatazione....ma questa è pratica faticosa e poco digeribile ai più...
>Cosa mi consigliate? Impongo un sistema organizzato? o organizzo un file system condiviso...che sarà caotico in men che non si dica?
>Il gruppo di lavoro ha già utilizzato geonetwork, che a mio modesto parere non è male, ma non è neanche il top per l'utente della strada...
>Aspetto commenti e suggerimenti...grazie, a presto...
>Eugenio
AFAIK

non esiste alternativa alle cartelle condivise mediante samba.

Io organizzerei due distinte aree di lavoro.
Una aperta al caos, in cui ogni utente ha la propria zona di lavoro e puo' fare e disfare come meglio crede.
Si sa' benissimo che cosi' il rischio (e' praticamente sicuro) è che in poco tempo ti ci ritrovi con copie su copie dei medesimi dati,
o, peggio ancora, con i medesimi dati sempre modificati in maniera differente tra i vari utenti.

Questa purtroppo e' una cosa irrisolvibile, e quindi non va combattuta , ma piuttosto va circoscritta.
Per questo farei due aree, appunto, una dove ogni utente fa come gli pare, e una altra, in cui scrivi solo te e in cui metti cio' che ' definitivo.
In maniera che sulle ultime e definitive versioni hai anche una metainformazione coerente e allineata.

Infatti il problema peggiore, e' quando hai una metainformazione che dice che nell'archivio ci sono 4 campi con determinati domini, poi apri l'archivio e scopri invece 6 campi e domini differenti.
Senza sapere bene perche' e' cosi', come mai e quando e' successo.

Poi , magari la spiegazione e' semplice, magari l'utente ha aggiunto un campo perche' gli serviva per una ualche elaborazione sua, e magari si e' accorto che i domini erano troppo pochi.
Per cui fa' le sue brave modifiche , ma "dimentica" di trascriverle nella MTD e quindi si perde quasi subito traccia della cosa.

Invece se la zona con gli archivi "ufficiali" e' gestita da un apposito responsabile e solo lui ci puo' scrivere, questo lo responsabilizza e garantisce che qualciasi cosa ci va a finire, almeno una persona sa' da dove quella roba proviene.

Ovviamente deve essere una persona responsabile, se invece e' un informatico "bove" spallato e scocciato che copia quello che gli passano senza chiedersi se sono vettori o cavoli, allora non serve a niente avere una area di dati ufficiali a sola lettura.

Per il resto, la scelta delle cartelle condivise via samba/cifs e' praticamente obbligata.
E' l'unica soluzione che ti permette di organizzare i dati in maniera gerarchica con percorsi che portano fino al dato da usare, e permette di impiegarli in sistema GIS per elaborazioni spaziali anche complesse.

Anche in questo caso pero' il lavoro del cosidetto "responsabile della area dei dati ufficiali" e' comunque importante.
Perch'e deve mantenere gli indici spaziali sempre aggiornati , per garantire il massimo delle performance agli utenti, e
ancora piu' importante.
DEVE cercare di mantenere i percorsi invariati.

Mi spiego meglio:

Deve studiare una gerarchia di cartelle che si presti ad accogliere anche dati futuri, non solo il presente, altrimenti sara' sempre un rimodulare le cartelle, con conseguente cambio dei perocrsi e quindi progetti qgis che oggi si aprono e domani non si aprono piu'.

Questo non deve succedere , almeno non deve succedere troppo spesso, altirmenti chi usa i dati si trova in difficolta' e lavora male.

Infine nel progettare queste cartelle tieni presente che esiste un limite ai percorsi.

Ad esempio noi cerchiamo dinon scendere mai sotto i 128 caratteri nel percorso delle cartelle perche' altrimenti arcview3 non legge piu' i dati.
QGIS va piu' lontano, ma su windows non credo che superi i 256 caratteri, per cui non vi e' comunque da scialare.

Una alternativa potrebbe essere l'impiego del DBMS, ma lo ritengo perdente in questo contesto.
Il DBMS non consetne la gerarchizzazione dei contesti e costringe a appiattire tutto al medesimo livello questo rende complicato l'impiego degli archivi quando cominciano a essere migliaia.

Noi, ad esempio, abbiamo migliaia di archivi di vario genere, e ognuno di essi ha almeno un utente per cui esso e' rilevante.
Senza contare gli utenti che ogni si affacciano ai nostri sistemi e cercano in maniera piu' o meno cosciente i dati che servono per il loro lavoro.
Una strutturazione degli archivi di tipo piatto non li aiuterebbe certamente nel loro lavoro.
Anche per questo la struttura gerarchica ottenibile con il filesystem e' imbattibile.

Un altro aspetto importante e' il contesto tecnologico in cui ti devi muovere, ovvero che tipo di archivi prevedono i tuoi utenti:

Se puoi spingerti oltre, io cercherei di abbinare l'impiego del filesystem con il formato spatialite (e prossimamente rasterlite),
perche' cosi' hai la combinazione di una struttura gerarchica a filesystem, con la potenza interrogativa di un database .
Collocando in ogni cartella della tua struttura gerarchica di cartelle uno o piu' file spatialite.

Noi stiamo adottando una tale strategia, e per ora i primi risultati sono incoraggianti.
Chiaramente e' un approccio ibrido, ma a mio parere porta dei vantaggi significativi.

L'unico vero svantaggio e' che attualmente spatialite' e visibile solo da QGIS, e quesot costringe a tenere a disposizione anche gli shapefile, che pero' con tutti i loro limiti finiscono per condizionare anche lo spatialite.
Intendo dire che cercando di tenere i medesimi dati nei due formati finisci per castrarti abbastanza rispetto alle possibilita' dello spatialite.


Infine nella cartella dove ci dovrebbe stare l'archivio ci metti 4 cartelle noi le chiamiamo cosi':
shp
splite
documenti
tabelle-varie

nella prima lo (o gli ) shapefile,

nella seconda il file splite che contiene tutti i medesimi dati della cartella shapefile,
nella terza tutti i documenti correlati , comprese le relazioni-tecniche (importanti per descrivere la qualita' del dato)
nella quarta eventuali dati non strettamente geografici, ma necessari per supportare la componente alfanumerica, ad esmepio fogli excel, file dbf, o altri formati.


--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
Reply | Threaded
Open this post in threaded view
|

Re: consigli su stoccaggio dati‏

giohappy
Grazie Andrea per avere condiviso il vostro metodo.
Sarebbe importante, come attività gfoss, documentare e tenere traccia di "best practices" open su problemi comuni di questo tipo...

giovanni

Il giorno 11 maggio 2012 11:19, Andrea Peri <[hidden email]> ha scritto:
>Ciao a tutti,chiederei consigli e opinioni riguardanti sistemi e sw da utilizzare per l'archiviazione, catalogazione e condivisione dati geografici e non ovviamente di tipo opensource.Sembra facile, ma non lo è, perchè chi ha accesso a questa condivisione dati ha le proprie abitudini e pretese in quanto a modalità di organizzazione, accesso, usabilità, ecc...Fissiamo dei punti:i dati sono digitali di ogni tipo, dai documenti doc, xls, ppt, pdf, jpg a quelli di tipo geografici localizzati e non di tipo raster e geografici vettoriali per lo più di tipo shp o ascii.I dati al momento da 'organizzare sono qualcosa come 1 Tb , con una velocità di espansione non elevatissima, diciamo circa 100 Gb anno??boh?forse è quasi troppo...
>Nel gruppo di lavoro c' è chi mi chiede una sorta di directory condivisa, con una organizzazione precisa delle sottodirectory, un modo insomma perchè tutti abbastanza 'amichevolmente' abbiano accesso alle varie directory....Questo secondo me crea il CAOS...quanto meno a lungo termine, senza considerare che dopo un pò di tempo ci si dimentica cosa viene stoccato chi l'ha stoccato,creando duplicati e versioni varie. A questo si aggiungono ovvi problemi di ricerca file.
>Sarebbe auspicabile un sistema catalogato, quindi organizzazione dati che passa da una metadatazione....ma questa è pratica faticosa e poco digeribile ai più...
>Cosa mi consigliate? Impongo un sistema organizzato? o organizzo un file system condiviso...che sarà caotico in men che non si dica?
>Il gruppo di lavoro ha già utilizzato geonetwork, che a mio modesto parere non è male, ma non è neanche il top per l'utente della strada...
>Aspetto commenti e suggerimenti...grazie, a presto...
>Eugenio
AFAIK

non esiste alternativa alle cartelle condivise mediante samba.

Io organizzerei due distinte aree di lavoro.
Una aperta al caos, in cui ogni utente ha la propria zona di lavoro e puo' fare e disfare come meglio crede.
Si sa' benissimo che cosi' il rischio (e' praticamente sicuro) è che in poco tempo ti ci ritrovi con copie su copie dei medesimi dati,
o, peggio ancora, con i medesimi dati sempre modificati in maniera differente tra i vari utenti.

Questa purtroppo e' una cosa irrisolvibile, e quindi non va combattuta , ma piuttosto va circoscritta.
Per questo farei due aree, appunto, una dove ogni utente fa come gli pare, e una altra, in cui scrivi solo te e in cui metti cio' che ' definitivo.
In maniera che sulle ultime e definitive versioni hai anche una metainformazione coerente e allineata.

Infatti il problema peggiore, e' quando hai una metainformazione che dice che nell'archivio ci sono 4 campi con determinati domini, poi apri l'archivio e scopri invece 6 campi e domini differenti.
Senza sapere bene perche' e' cosi', come mai e quando e' successo.

Poi , magari la spiegazione e' semplice, magari l'utente ha aggiunto un campo perche' gli serviva per una ualche elaborazione sua, e magari si e' accorto che i domini erano troppo pochi.
Per cui fa' le sue brave modifiche , ma "dimentica" di trascriverle nella MTD e quindi si perde quasi subito traccia della cosa.

Invece se la zona con gli archivi "ufficiali" e' gestita da un apposito responsabile e solo lui ci puo' scrivere, questo lo responsabilizza e garantisce che qualciasi cosa ci va a finire, almeno una persona sa' da dove quella roba proviene.

Ovviamente deve essere una persona responsabile, se invece e' un informatico "bove" spallato e scocciato che copia quello che gli passano senza chiedersi se sono vettori o cavoli, allora non serve a niente avere una area di dati ufficiali a sola lettura.

Per il resto, la scelta delle cartelle condivise via samba/cifs e' praticamente obbligata.
E' l'unica soluzione che ti permette di organizzare i dati in maniera gerarchica con percorsi che portano fino al dato da usare, e permette di impiegarli in sistema GIS per elaborazioni spaziali anche complesse.

Anche in questo caso pero' il lavoro del cosidetto "responsabile della area dei dati ufficiali" e' comunque importante.
Perch'e deve mantenere gli indici spaziali sempre aggiornati , per garantire il massimo delle performance agli utenti, e
ancora piu' importante.
DEVE cercare di mantenere i percorsi invariati.

Mi spiego meglio:

Deve studiare una gerarchia di cartelle che si presti ad accogliere anche dati futuri, non solo il presente, altrimenti sara' sempre un rimodulare le cartelle, con conseguente cambio dei perocrsi e quindi progetti qgis che oggi si aprono e domani non si aprono piu'.

Questo non deve succedere , almeno non deve succedere troppo spesso, altirmenti chi usa i dati si trova in difficolta' e lavora male.

Infine nel progettare queste cartelle tieni presente che esiste un limite ai percorsi.

Ad esempio noi cerchiamo dinon scendere mai sotto i 128 caratteri nel percorso delle cartelle perche' altrimenti arcview3 non legge piu' i dati.
QGIS va piu' lontano, ma su windows non credo che superi i 256 caratteri, per cui non vi e' comunque da scialare.

Una alternativa potrebbe essere l'impiego del DBMS, ma lo ritengo perdente in questo contesto.
Il DBMS non consetne la gerarchizzazione dei contesti e costringe a appiattire tutto al medesimo livello questo rende complicato l'impiego degli archivi quando cominciano a essere migliaia.

Noi, ad esempio, abbiamo migliaia di archivi di vario genere, e ognuno di essi ha almeno un utente per cui esso e' rilevante.
Senza contare gli utenti che ogni si affacciano ai nostri sistemi e cercano in maniera piu' o meno cosciente i dati che servono per il loro lavoro.
Una strutturazione degli archivi di tipo piatto non li aiuterebbe certamente nel loro lavoro.
Anche per questo la struttura gerarchica ottenibile con il filesystem e' imbattibile.

Un altro aspetto importante e' il contesto tecnologico in cui ti devi muovere, ovvero che tipo di archivi prevedono i tuoi utenti:

Se puoi spingerti oltre, io cercherei di abbinare l'impiego del filesystem con il formato spatialite (e prossimamente rasterlite),
perche' cosi' hai la combinazione di una struttura gerarchica a filesystem, con la potenza interrogativa di un database .
Collocando in ogni cartella della tua struttura gerarchica di cartelle uno o piu' file spatialite.

Noi stiamo adottando una tale strategia, e per ora i primi risultati sono incoraggianti.
Chiaramente e' un approccio ibrido, ma a mio parere porta dei vantaggi significativi.

L'unico vero svantaggio e' che attualmente spatialite' e visibile solo da QGIS, e quesot costringe a tenere a disposizione anche gli shapefile, che pero' con tutti i loro limiti finiscono per condizionare anche lo spatialite.
Intendo dire che cercando di tenere i medesimi dati nei due formati finisci per castrarti abbastanza rispetto alle possibilita' dello spatialite.


Infine nella cartella dove ci dovrebbe stare l'archivio ci metti 4 cartelle noi le chiamiamo cosi':
shp
splite
documenti
tabelle-varie

nella prima lo (o gli ) shapefile,

nella seconda il file splite che contiene tutti i medesimi dati della cartella shapefile,
nella terza tutti i documenti correlati , comprese le relazioni-tecniche (importanti per descrivere la qualita' del dato)
nella quarta eventuali dati non strettamente geografici, ma necessari per supportare la componente alfanumerica, ad esmepio fogli excel, file dbf, o altri formati.


--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
Reply | Threaded
Open this post in threaded view
|

Re: consigli su stoccaggio dati‏

margherita


2012/5/11 G. Allegri <[hidden email]>
Grazie Andrea per avere condiviso il vostro metodo.
Sarebbe importante, come attività gfoss, documentare e tenere traccia di "best practices" open su problemi comuni di questo tipo...

c'e` il wiki! :)

ciao madi 

giovanni

Il giorno 11 maggio 2012 11:19, Andrea Peri <[hidden email]> ha scritto:
>Ciao a tutti,chiederei consigli e opinioni riguardanti sistemi e sw da utilizzare per l'archiviazione, catalogazione e condivisione dati geografici e non ovviamente di tipo opensource.Sembra facile, ma non lo è, perchè chi ha accesso a questa condivisione dati ha le proprie abitudini e pretese in quanto a modalità di organizzazione, accesso, usabilità, ecc...Fissiamo dei punti:i dati sono digitali di ogni tipo, dai documenti doc, xls, ppt, pdf, jpg a quelli di tipo geografici localizzati e non di tipo raster e geografici vettoriali per lo più di tipo shp o ascii.I dati al momento da 'organizzare sono qualcosa come 1 Tb , con una velocità di espansione non elevatissima, diciamo circa 100 Gb anno??boh?forse è quasi troppo...
>Nel gruppo di lavoro c' è chi mi chiede una sorta di directory condivisa, con una organizzazione precisa delle sottodirectory, un modo insomma perchè tutti abbastanza 'amichevolmente' abbiano accesso alle varie directory....Questo secondo me crea il CAOS...quanto meno a lungo termine, senza considerare che dopo un pò di tempo ci si dimentica cosa viene stoccato chi l'ha stoccato,creando duplicati e versioni varie. A questo si aggiungono ovvi problemi di ricerca file.
>Sarebbe auspicabile un sistema catalogato, quindi organizzazione dati che passa da una metadatazione....ma questa è pratica faticosa e poco digeribile ai più...
>Cosa mi consigliate? Impongo un sistema organizzato? o organizzo un file system condiviso...che sarà caotico in men che non si dica?
>Il gruppo di lavoro ha già utilizzato geonetwork, che a mio modesto parere non è male, ma non è neanche il top per l'utente della strada...
>Aspetto commenti e suggerimenti...grazie, a presto...
>Eugenio
AFAIK

non esiste alternativa alle cartelle condivise mediante samba.

Io organizzerei due distinte aree di lavoro.
Una aperta al caos, in cui ogni utente ha la propria zona di lavoro e puo' fare e disfare come meglio crede.
Si sa' benissimo che cosi' il rischio (e' praticamente sicuro) è che in poco tempo ti ci ritrovi con copie su copie dei medesimi dati,
o, peggio ancora, con i medesimi dati sempre modificati in maniera differente tra i vari utenti.

Questa purtroppo e' una cosa irrisolvibile, e quindi non va combattuta , ma piuttosto va circoscritta.
Per questo farei due aree, appunto, una dove ogni utente fa come gli pare, e una altra, in cui scrivi solo te e in cui metti cio' che ' definitivo.
In maniera che sulle ultime e definitive versioni hai anche una metainformazione coerente e allineata.

Infatti il problema peggiore, e' quando hai una metainformazione che dice che nell'archivio ci sono 4 campi con determinati domini, poi apri l'archivio e scopri invece 6 campi e domini differenti.
Senza sapere bene perche' e' cosi', come mai e quando e' successo.

Poi , magari la spiegazione e' semplice, magari l'utente ha aggiunto un campo perche' gli serviva per una ualche elaborazione sua, e magari si e' accorto che i domini erano troppo pochi.
Per cui fa' le sue brave modifiche , ma "dimentica" di trascriverle nella MTD e quindi si perde quasi subito traccia della cosa.

Invece se la zona con gli archivi "ufficiali" e' gestita da un apposito responsabile e solo lui ci puo' scrivere, questo lo responsabilizza e garantisce che qualciasi cosa ci va a finire, almeno una persona sa' da dove quella roba proviene.

Ovviamente deve essere una persona responsabile, se invece e' un informatico "bove" spallato e scocciato che copia quello che gli passano senza chiedersi se sono vettori o cavoli, allora non serve a niente avere una area di dati ufficiali a sola lettura.

Per il resto, la scelta delle cartelle condivise via samba/cifs e' praticamente obbligata.
E' l'unica soluzione che ti permette di organizzare i dati in maniera gerarchica con percorsi che portano fino al dato da usare, e permette di impiegarli in sistema GIS per elaborazioni spaziali anche complesse.

Anche in questo caso pero' il lavoro del cosidetto "responsabile della area dei dati ufficiali" e' comunque importante.
Perch'e deve mantenere gli indici spaziali sempre aggiornati , per garantire il massimo delle performance agli utenti, e
ancora piu' importante.
DEVE cercare di mantenere i percorsi invariati.

Mi spiego meglio:

Deve studiare una gerarchia di cartelle che si presti ad accogliere anche dati futuri, non solo il presente, altrimenti sara' sempre un rimodulare le cartelle, con conseguente cambio dei perocrsi e quindi progetti qgis che oggi si aprono e domani non si aprono piu'.

Questo non deve succedere , almeno non deve succedere troppo spesso, altirmenti chi usa i dati si trova in difficolta' e lavora male.

Infine nel progettare queste cartelle tieni presente che esiste un limite ai percorsi.

Ad esempio noi cerchiamo dinon scendere mai sotto i 128 caratteri nel percorso delle cartelle perche' altrimenti arcview3 non legge piu' i dati.
QGIS va piu' lontano, ma su windows non credo che superi i 256 caratteri, per cui non vi e' comunque da scialare.

Una alternativa potrebbe essere l'impiego del DBMS, ma lo ritengo perdente in questo contesto.
Il DBMS non consetne la gerarchizzazione dei contesti e costringe a appiattire tutto al medesimo livello questo rende complicato l'impiego degli archivi quando cominciano a essere migliaia.

Noi, ad esempio, abbiamo migliaia di archivi di vario genere, e ognuno di essi ha almeno un utente per cui esso e' rilevante.
Senza contare gli utenti che ogni si affacciano ai nostri sistemi e cercano in maniera piu' o meno cosciente i dati che servono per il loro lavoro.
Una strutturazione degli archivi di tipo piatto non li aiuterebbe certamente nel loro lavoro.
Anche per questo la struttura gerarchica ottenibile con il filesystem e' imbattibile.

Un altro aspetto importante e' il contesto tecnologico in cui ti devi muovere, ovvero che tipo di archivi prevedono i tuoi utenti:

Se puoi spingerti oltre, io cercherei di abbinare l'impiego del filesystem con il formato spatialite (e prossimamente rasterlite),
perche' cosi' hai la combinazione di una struttura gerarchica a filesystem, con la potenza interrogativa di un database .
Collocando in ogni cartella della tua struttura gerarchica di cartelle uno o piu' file spatialite.

Noi stiamo adottando una tale strategia, e per ora i primi risultati sono incoraggianti.
Chiaramente e' un approccio ibrido, ma a mio parere porta dei vantaggi significativi.

L'unico vero svantaggio e' che attualmente spatialite' e visibile solo da QGIS, e quesot costringe a tenere a disposizione anche gli shapefile, che pero' con tutti i loro limiti finiscono per condizionare anche lo spatialite.
Intendo dire che cercando di tenere i medesimi dati nei due formati finisci per castrarti abbastanza rispetto alle possibilita' dello spatialite.


Infine nella cartella dove ci dovrebbe stare l'archivio ci metti 4 cartelle noi le chiamiamo cosi':
shp
splite
documenti
tabelle-varie

nella prima lo (o gli ) shapefile,

nella seconda il file splite che contiene tutti i medesimi dati della cartella shapefile,
nella terza tutti i documenti correlati , comprese le relazioni-tecniche (importanti per descrivere la qualita' del dato)
nella quarta eventuali dati non strettamente geografici, ma necessari per supportare la componente alfanumerica, ad esmepio fogli excel, file dbf, o altri formati.


--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012



--
Ing. Margherita Di Leo, Ph.D.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
Reply | Threaded
Open this post in threaded view
|

Re: consigli su stoccaggio dati‏

frippe12573
In reply to this post by Andrea Peri
> From: Andrea Peri <[hidden email]>
> To: [hidden email]
> Subject: [Gfoss] consigli su stoccaggio dati‏
Ciao Andrea, 
grazie per i consigli, avrei però ancora dei dubbi e punti da chiarire:
concordo sul fatto che samba garantisca una buona familiarità di utilizzo per i vari utenti,
le cartelline, i drag end drop, ctrl-c ctrl-v sono attività che ormai tutti sono capaci di svolgere
concorderei anche sulla possibilità di creare 2 aree, 
ma l'area in sola lettura diventerebbe solamente un archivio? dati stoccati e non più utilizzati?
gli utenti utilizzerebbero i dati a cui hanno accesso sia in scrittura che lettura?
 il lavoro del responsabile dati che deve poi migrare i dati dalla zona open alla zona restricted
diventerebbe enorme, se non viene stabilito un flusso di lavoro sul dato, un metodo di metadatazione
a monte...o no? a questo aggiungerei grossi problemi di ricerca!!
credo sia necessario una sorta di protocollo e flusso di lavoro sui dati che non prescinde da una metadatazione.
A questo aggiungerei che le operazioni di ricerca diventerebbero difficoltose, anche all'interno delle dir create e 
gestite dagli utenti, specie quando si creano molte dir annidate e i dati sono molti Gb.

Un'altro aspetto che valuterei è come stoccare i dati geografici, db alla grass (divisi per location)o dati ripetuti nelle varie dir 
progettuali come suggerivi? non si crea ridondanza e Tb buttati?

In sostanza direi che concettualmente preferirei organizzare tutto x mezzo di un catalogo dati stoccati in un dbms, per questioni
legate a maggiore potenza di ricerca e 'credo' ad un maggior controllo sui dati usati e prodotti dagli utenti,
ma riconosco che l'approccio samba/file system è di gran lunga il più 'digerito' tra gli utenti, sebbene però molti 
dubbi  ancora mi rimangono.

Saluti

Eugenio





_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012