Newsgroup: it.comp.www.php
Titolo: Database "imponente"

Ciao devo realizzare un database con dati finanziari che contenga :
titolo, data,open,close,highi,volume,paniere,mercato
Il database parte con 5 ani di storico , il che significa inserire 8.800.000
quotazioni
e dopo verranno inserite 5.600 quotazioni "al giorno", il che significa
un'alto numero di operazioni
sul database e sopratutto una vasta marea di dati sulla quale effettuare
molte ricerche
Moltissime operazioni (circa 20) per i calcoli finanziari e la realizzazione
di grafici verranno fatti al volo
Pensavo a questa struttura :
Tabella titoli
AID
PANIERE
MERCATO
Table quotazioni
ID
AID
DATA
OPEN
HIGH
LOW
CLOSE
VOLUME
che ne dite ? La struttura mi sembra l'unica soluzione , ma magari è
possibile ottimizzarla ancora ?
Mysql può avere problemi con queste mole di dati ?

 Mysql puň avere problemi con queste mole di dati ?
assolutamente no.
se vuoi incrementare le prestazioni basta tenere d'occhio le queries 
(query cache), c'č un articolo interessante qui:
http://www.mysql.com/newsletter/2003-01/a0000000108.html
e le impostazioni di memoria in generale (per questo, prendi in edicola 
l'ultimo numero di Linux & C. anche se non č proprio una bibbia).
occhio anche agli indici.
ciao
-- 
punkarruso

 Mysql può avere problemi con queste mole di dati ?
Guarda, avevo un sito web che faceva piu' o meno quello che devi fare tu.
Caricava ogni minuto le quotazioni di tutte le borse europee e americane,
tenendo anche lo storico, con grafici in tempo reale, statistiche e
strumenti di analisi anche molto complessi.
Mysql ci stava dentro benissimo.
Non altrettanto si puo' dire del sistema Radiocor che doveva fornire i dati
(basato su MS SQL Server), ma questa e' un'altra storia.
S*


thks , :))
AID rappresenta l'id della terna : azione , paniere, gruppo , che è univoca
specifico :
ho deciso di scindere e fare una tabella azioni perché ho : 3 gruppi che
contengono 15 panieri che contengono un totale di 5500 azioni
mentre l'altra tabella è quella che conterrà la massa di dati
le due tabelle sono collegate da AID con un rapporto 1->Molti
questa mi sembra la soluzione migliore , che dite ?

 con un pII, linux e 92Mb di ram non penso a problemi molto grandi.
In realtà il dimensionamento di una macchina è un po più complicato...un
sito che in un giorno crea 5.600 record nuovi non è un sito casalingo, credo
quindi che debba garantire certi servizi. Pentium II, Linux e 92 MB?? E che
ci fai? Hai calcolato la velocità di accesso al/ai disco/i? E' previsto un
sistema raid su quella macchina? Queste sono le prime cose che io mi
chiederei...quali servizi girano, punte massimpo di carico, minine e
stimate...come e quanto crescono le tabelle (molto velocemente direi a
giudicare dalla mole di dati di cui si parla). Ho visto server mooolto più
carrozzati per servizi che gestivano una mole di dati nettamente inferiore.
92 MB non ce l'ho manco io sul mio pc :))
Secondo me, ma è solo una mia impressione, perchè non conosco il contesto di
cui si parla, quello che il nostro amico dice non è sufficente per dare una
stima dell'hardware consigliato. In più, la macchina che te descrivi mi
sembra abbastanza...limitata.
Rispondimi alla parte di mysql che mi interessa di più :)
Saluti...
--------------------------------
Inviato via 
http://usenet.libero.it

 Rispondimi alla parte di mysql che mi interessa di più :)
sul dimensionamento fai finta che non abbia detto niente.
ieri ho mangiato qualcosa che non andava in mensa e mi ha fatto fare 
tante ca**ate come non ne faccio in un anno... non solo qui!
chiedo venia per la fesseria!
ciao
-- 
punkarruso

 significativo che non sia un 'auto_increment' come ho già suggerito...
tipo ?
thks
ciao

 tipo ?
AID + data. viene duplicato?
così non ti servirebbero neanche altri indici e ci risparmi pure spazio.
(un indice sui due valori penso che ci andrebbe comunque)
ciao
-- 
punkarruso

 ciao
su questo punto sono duro :( , cioé non riesco a capire esattamente il 
problema . 
Io ho messo AID , codice univo che riassume la combinazione : 
azione - aniere e gruppo
Tu dici che sarebbe meglio definire una chiave con qualcosa di 
significativo, presumo quindi un valore "reale" , giusto ?
Ma su quale tabella ?
Propobni AID + data , perché ?
Scusa ma vorrei capire meglio perché questa scelta di progettazione 
thks
ciao

 Propobni AID + data , perché ?
non ne so niente di finanza, quindi le mie sono tutte congetture:
se hai 5600 AID diverse al giorno, non hai 2 AID lo stesso giorno.
ecco che AID+data ti rappresenta il record di QUELL'AID per QUEL giorno.
(se non funziona così ignora quello che dico)
se fai un grafico di riassunto, immagino che la ricerca sarà where AID = 
'$AID' and data between '$inizio' and '$fine'.
ovvero: fai la ricerca direttamente sulla chiave.
ciao
-- 
punkarruso

 ciao
si , diciamo che la tabella  titoli contiene 5600 azioni , per sempre , 
controllate ed aggiornate ma non di +.
quindi non avrò 5600 aid diverse al giorno ma 5600 in totale , sempre.
Io inseriso 5600 "quotazioni" al giorno , quindi sarà la tabella quotazioni 
a ricevere 5600 inserimenti :)
Che ne pensi ??
scusa se do per scontate alcune cose e grazie per l'enorme aiuto che mi 
stai dando .
Ad oggi non avevo mai affrontato un database di questa entità , e vorrei 
dedicarmi il più possibile alla progettazione , in modo da non avere poi 
brutte sorprese .
;) Bye

 calcolato, visto che la data viene utilizzata per fare svariati calcoli...
no. per AID + data non intendo la loro concatenazione ! :-)
intendo una primary key costruita su entrambi i campi:
create table titoli (
	AID integer not null primary key, -- anche auto_increment?
	AZIONE varchar(x) not null,
	PANIERE varchar(x) not null,
	MERCATO varchar(x)) not null);
create table quotazioni (
      aid integer not null, --setta eventuale FK (mysql se ne frega)
      data date not null,
      open numeric(11,2), --null?
      high numeric (11,2), --null?
      low numeric(11,2), --null?
      close numeric(11,2), --null?
      volume integer, --null?
      primary key (aid, data)); -- chiave su 2 campi!!!
<snip>
il resto, tutto ok.
se ti sono stato utile puoi darmi il tuo indirizzo così ti spedisco la 
parcella... :-)
ciao
-- 
punkarruso

 ciao
[:-)] ehm , .. dai sii buono con un poverlo libero professionista , 
tartassato da mille spese e tasse dal ns caro stato :))
PS. 
sto preparando le operazioni che stimavo di fare al volo, sono molte e 
abbastanza complesse, quindi penso che mi converrà creare una terza 
tabella , tipo :
 create table indici_tec (
       aid integer not null, 
       data date not null,
       oper1 int(11),
       oper2 int(11),
       oper3 int(11),
       primary key (aid, data));
che quindi avrò la chiave primaria identica , giustamente , alla tabella 
quotazioni .
Vorrei approfittare della tua conoscenza sui dbase e mysql : cosa può 
succedere secondo te se parte delle operazioni di upload delle quotazioni 
devono obbligatoriamente essere eseguite alle 10,30 di mattina, quanto il 
traffico sul sito potrebbe essere notevole , e quindi anche gli accessi 
al database ?
THKS 
Bye

 al database ?
probabilmente niente. l'efficienza durante il caricamento dipenderà 
molto dall'architettura (rete) e dalla procedura di caricamento stessa:
solo le prove potranno dirlo.
finché ti riesce, cerca di ottimizzare al massimo tutti gli step.
le idee belle vengono quasi sempre quando vedi nascere il problema...
ciao
-- 
punkarruso

 wrote in
news:4IX9a.184973$
ZE.55...@twister2.libero.it
: 

Ciao e grazie per il supporto ;)