[Linuxtrent] consiglio su db
- From: Luca Manini <manini@xxxxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Thu, 17 Oct 2002 16:23:08 +0200
>>>>> "Emanuele" == Emanuele Olivetti <olivetti@xxxxxx> writes:
Premetto la mia gnuranza in fatto di DB, ma siccome ti hanno
risposto proprio tutti, mi lancio anch'io in un paio di
osservazioni.
Emanuele> Sto valutando la possibilita' di utilizzare un db per
Emanuele> gestire i dati per un' applicazione di analisi dati da
Emanuele> fare in c++ su linux e non so orientarmi.
Analisi dati mi pare un po' generico, no? (sarà che ho appena
letto un documento su come fare le domande affinché i guru
ti rispondano qualcosa di diverso da RTFM).
Con analisi intendi che i dati ci sono già, quindi tutto il lavoro
è a bocce ferme (grandi analisi su un DB vivo sono un gran
casino)?
Se sì mi viene da dire che di transazioni e atomicità forse non
sai cosa fartene (credo) e che la struttura sarà più di quella di
un DB di data-warehousing (poca roba relazionale, grande
ridondanza, tonnellate di indici precalcolati) che di OLAP (evvai
di buzzword).
Insomma, dicci qualcosa di più.
Emanuele> I vincoli sono:
Emanuele> 1) bisogna cercare la massima efficienza (performance)
Emanuele> perche' precedentemente il tutto veniva gestito tenendo
Emanuele> i dati su file ed era una scheggia. Ovviamente la
Emanuele> velocita' dipende anche da cosa voglio fare dei dati e
Emanuele> come li strutturo, ma questo e' un altro discorso.
A parte stare su file, è necessario poter usare SQL o no? Se sì,
mettere tutto in un DB è un buon sistema di avere l'SQL, ma forse
è il caso di vedere se l'SQL di turno ha le funzioni di (supporto
per) analisi che ti servono (dovercele aggiungere non è proprio
una libidine).
Emanuele> 2) i record potrebbero essere dell'ordine di 500.000 -
Emanuele> 1.000.000
Magari se ci dici anche quante sono le tabelle, o meglio ci dai
una idea di tabelle -> numero-di-record...
Emanuele> 3) il record e' composto da meno di una decina
Emanuele> di campi quasi tutti numerici (int, float ecc.) e magari
Emanuele> un paio di brevi stringhe (< 10 caratteri).
Come IL record, non erano tanti :-)
La matematica non è il mio forte, ma 1M * (10 * 4 + 2 * 10) ci sta
tutto in memoria, anche pensando ad un overhead del 100% di indici
(o parenti). A meno che le tabelle da 1M record non siano tante...
Emanuele> 4) vorrei un db "libero" (quindi non consigliatemi
Emanuele> oracle)
Lungi da me
Emanuele> 5) deve interfacciarsi bene con il c++ (questo penso sia
Emanuele> il problema minore)
Nel senso che quasi tutti si interfacciano con il c++? Può
darsi. Che poi "usare" il c++ sia un problema
minore...degustibus.
bye, Luca
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con SOGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: