Newsgroup: it.comp.lang.visual-basic
Titolo: [?]Richiesta consiglio su archiviazione dati

Salve a tutti,
mi trovo ogni giorno a lavorare con una mole immensa
di dati. Per inciso mi occupo (fra le altre) di sistemi
di analisi e graficazione di dati di borsa, a breve e
lungo termine, in tempo reale e non.
Ad oggi, il sistema usato per l'archiviazione dei dati
(aquisiti in tempo reale giorno per giorno) consiste in
file di testo che nel nome riportano data e titolo/indice,
e che contengono orario e vari campi numerici (il valore
del titolo e altri).
Le analisi (di varia natura) effettuate su tali dati (in
tempo reale e non) vengono memorizzate in altrettanti
file di testo in modo da poter essere richiamate
rapidamente (sia da sw proprietario sia da excel, per
elaborazioni successive).
Evidentemente i dati cosi' archiviati occupano molto
spazio, ed i tempi di accesso/lettura sono quelli
intrinseci dei file di testo (nel bene e nel male).
In questi giorni ho deciso di riprogettare/sviluppare
interamente tutti i software che utilizziamo, in .NET.
In particolare la questione della modalita' di
archiviazione dei dati "mi e'" fondamentale perche':
- l'accesso a tali dati cosi' come sono, ma anche con
  filtri (query?) specifici, deve essere il piu' veloce
  ed efficiente possibile;
- le analisi effettuate sui dati devono poter essere
  salvate e richiamate altrettanto velocemente;
- i dati devono poter essere salvati (da una singola
  istanza di una sola applicazione) in tempo reale,
  uno ad uno, rapidamente e senza interruzione di sorta;
- l'accesso a tali dati deve poter essere concorrenziale
  (in lettura) da piu' applicazioni;
- i dati devono poter essere scambiati/aggiornati
  facilmente da/su piu' pc in rete e su internet,
  tendenzialmente in modo indipendente dal s.o. e dalla
  piattaforma che li elaborera'.
Date queste specifiche imprescindibili, gradirei avere la
vostra opinione riguardo al miglior metodo di
archiviazione.
Personalmente ritengo che i file di testo continuino ad
essere la miglior soluzione (lo spazio in realta' e' un
problema marginale), pur avendo il difetto di non poter
essere "filtrati" se non con apposite ricerche su tutto
il file/tutti i file.
Le altre soluzioni piu' o meno praticabili che mi vengono
in mente sono l'uso di Database (quale? e' indispensabile
che sia totalmente free. MySql? Boh!) o di XML che in
qualche modo ha un po' dei pregi di entrambi (file di testo
e database).
Attendo fiducioso i vostri commenti.
Grazie,
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org

Ciao!
Cutto tutto e ti rispondo subito: indubbiamente la tua soluzione si chiama
MySQL... Dimentica i file di testo...
                Ciao
                                        Allanon
--
- SPAMKILLER
 L'indirizzo delle risposte é 
itlangv...@michele.sytes.net
 LASCIATE il NOSPAM fa parte dell'indirizzo :-)
  Per superare le impostazioni di protezione antispam scrivete
  nel testo del messaggio la scritta "SPAMKILLER"
Scusate il disturbo, ma non posso più di pubblicità

 MySQL... Dimentica i file di testo...
Mi risulta che il provider .NET per MySQL sia di terze parti e
soprattutto non solo non e' free, ma richiede anche una licenza
commerciale di MySQL!
Lokar.punto.e.a.capo


 Attendo fiducioso i vostri commenti.
A dire il vero speravo in un contributo piu' massiccio :) soprattutto
dai big del ng in materia di archiviazione...
Lokar.ancora.fiducioso


 A dire il vero speravo in un contributo piu' massiccio :)
questo non è spam perchè sei stato tu a sollecitarlo :-)
Scherzi a parte
1) problema di spazio: credo che i file di testo siano la forma di archiviazione
dati che occupa il minor spazio possibile, se per te è un must regolati, ma con
il prezzo attuale dei gb su disco, direi di tralasciare il discorso
2) problema database: se hai 
vs.net
 professional, dovresti avere anche msde, la
versione "light" di sql server, gratis e anche redistribuibile
3) interscambio dei dati: salvataggio dei medesimi in formato xml.
just my two eurocent
(comunicare i dati per l'invio della fattura)
--
Salutoni
Sergio

 commerciale di MySQL!
Io ne ho scaricata una versione Open source scritta in C#... L'ho trovata
partendo da 
http://www.ugidotnet.org
 non ricordo il link preciso...
Comunque nessuno ti vieta di accedere con il provider per ODBC che ti puoi
gratuitamente scaricare dal sito Microsoft (ed era compreso fino alla
beta... e tornerà dalla versione 2003)!
Credimi, gestire un formato proprietario é un bello "sbattimento" che
difficilmente vale la pena di affrontare...


 commerciale di MySQL!
Domanda tecnica: ma il provider MyOleDb (che si scarica gratuitamente e che
sul sito viene presentato come Royalty-free), che con Ado va benissimo,
perchè non dovrebbe funzionare con Ado.Net (premetto che non l'ho mai
provato con .Net)?
Ciao
Alberto

 non l'ho mai provato con .Net)?
risposta tecnica approssimativa: l'utilizzo di ADO (e quindi di tutti i suoi
provider) all'interno di .NET è possibile ma sconsigliato, perchè comporta
l'introduzione di un ulteriore "strato software" per l'accesso a COM (frase che
scrivo perchè "riempie" bene la bocca, ma gallina beccami se so esattamente che
cosa vuol dire) con un deciso decadimento delle prestazioni.
Per 
ADO.NET
 devono essere utilizzati i provider appositamente costruiti per
questo ambiente.
--
Salutoni
Sergio

 i suoi provider)
Ecco. Il mio dubbio nasce da qui. I provider (almeno come li ho sempre
intesi io), non sono "per Ado" o per altro.
Sono provider.
Tant'è, che anche attività che non usano Ado (almeno esplicitamente), come
ad esempio i DTS o le interconnessioni fra server Sql o MSDE con altre fonti
dati, si appoggiano a questi stessi provider.
Ero quindi convinto che un provider, se funzionava con Ado, potesse
funzionare tranquillamente con Ado.Net.
Poi, nulla vieta che esistano provider 'ottimizzati' per l'uso attraverso
Ado.Net, ma non vedevo l'impossibilità di usare Ado.Net appoggiandosi su
provider OleDb o ODBC comuni, come Jet, SqlOleDb, MyOleDb, ecc...
Ciao
Alberto

 Sono provider.
per quanto mi riguarda puoi anche avere ragione: cerco di conciliare le tue
affermazioni con quanto ho letto su 
ado.net
: i provider da te citati non sono
direttamente legati ad ado, ma sfruttano comunque lo "strato di interoperabilità
COM" per poter essere utilizzati dalle applicazioni, quindi se li vuoi usare
all'interno di .net ti devi tirare dietro quello strato in più, cosa che non
fanno i provider espressamente disegnati per quell'ambiente. (nota del
redattore: al momento sono disponibili da microsoft, praticamente, solo i
provider per sql (con classe "dedicata", quindi particolarmente performante),
Access e oracle, quest'ultimo affetto da qualche fastidioso buchetto, pare ;-) )
--
Salutoni
Sergio

 (comunicare i dati per l'invio della fattura)
ROTFL :)
Grazie mille,
Lokar


 doppio o il triplo dello spazio!
si, ma è uno standard pubblico e "autodescritto" (per quel poco che ho visto,
neh), quindi ti permette di scambiare i dati con maggiore facilità. Certo che se
le applicazioni tra cui i dati vengono scambiati le scrivi tutte tu, il problema
non si pone.
--
Salutoni
Sergio

 la controprova.
prova a pensare allo zip di un txt.
se i puntatori nel relazionale sono numerici e le stringhe te le tiri solo
dietro, mettere i dati in binario ottimizzerebbe mica poco.
e i pc coi numeri lavorano molto meglio...
ciao
a.che.non.ci.pensa.proprio.e.denormalizza.quanto.puo' :)

 a.che.non.ci.pensa.proprio.e.denormalizza.quanto.puo' :)
Ho notato che in un tuo precedente post ti è scappata una maiuscola, quindi
posso arguire due cose
1) la tua tastiera funziona correttamente (almeno qualche volta)
2) il 2003 ha portato un altra variazione, oltre a quelle già segnalate
--
Salutoni
Sergio

 provato con .Net)?
Nessuno ti vieta di farlo, ma...
Il percorso di un provider 
ADO.NET
 nativo é questo:
MySQL - 
ADO.NET
 - Tua Applicazione
Se usi il MyOLEDB che a sua volta usa il MyODBC:
MySQL - MyODBC - MyOLEDB - 
ADO.NET
 - Tua Applicazione
Il dubbio di un crollo di prestazioni (e forse anche di affidabilità) c'é ed
é elevato! :)
Per tanto così usa il provider nativo di 
ADO.NET
 per ODBC:
MySQL - MyODBC - 
ADO.NET
 - Tua Applicazione


 MySQL - MyODBC - MyOLEDB - 
ADO.NET
 - Tua Applicazione
Qui ho qualche dubbio. Io ho MyOleDb, ma non ho mai installato MyODBC.
Sei sicuro che MyOleDb si appoggi a MyODBC?
Pensa che, dovendo connettere il mio Sql-Server locale di test con un MySql
in Lan, l'opzione di usare MyODBC non c'era neppure, proprio perchè non l'ho
mai installato. E nel wizard degli ODBC MyODBC non c'è proprio.
Eppure MyOleDb funziona benissimo...
Ciao
Alberto

 MySQL - MyODBC - 
ADO.NET
 - Tua Applicazione
Grazie per le delucidazioni!
E grazie anche a tutti coloro che si stanno interessando.
Lokar


 2) il 2003 ha portato un altra variazione, oltre a quelle già segnalate
c'e' caso ne porti parecchie. vediamo.
ciao

 orrore ? dove ? sara' senz'altro stato un link o una citazione :)
no, per sottolineare un mio (ma comune) errore sintattico: dal tuo post con
oggetto
Re:api?[OT] del 03/03/03 (bella data, non dą adito a fraintendimenti)
"ma mi sembra che qc di simile allA api ci"
--
Salutoni
Sergio

 "ma mi sembra che qc di simile allA api"
ah ecco :)
e' che questo portatile nuovo e' una bella macchina, ma una mente malata ha
messo (oltre a home/end col function, che specie in vb e' veramente scomodo)
i ">" "<" a destra dove di solito c'e' il sottolineato. quindi per
sottolineare a norma ancora dovrei guardarci ogni volta....
senza dire che quando faccio
    if a > b then
al momento mi diventa sempre
    if a b then
e me ne accorgo a runtime :)
ciao
non e' mia abitudine, ma stavolta mi auguro che il progettista dell'auto del
progettista di questa tastiera gli abbia invertito gas e freno.