View Full Version : Database su gioco borsa..
The Incredible
23-05-2006, 22:22
Ho tirato a grandi linee giù il database per un ipotetico portafoglio virtuale..
Tabelle:
UTENTE (Informazione su utente, chiave idutente)
POSSIEDE_PORT (table che collega UTENTE e PORTAFOGLIO key primary idutente and idport che foreign e key foreign)
PORTAFOGLIO (key primary adn foreignare idport and codazione)
AZIONI(key primary is codazione, this table contain the information of azione)
APPARTENGONO (tabella che collega AZIONI con INDICI, key primary and foreign idindice and idazione)
INDICI (idindice key primary, contiene informazioni sull'indice)
che ne dite?
potrebbero bastare queste tabelle..
esistono software che aiutano nella generazione e implementazione di database, o meglio per disegnare e progettarli su pc?
utilizzo mysql e php
Grazie
Ho tirato a grandi linee giù il database per un ipotetico portafoglio virtuale..
Tabelle:
UTENTE (Informazione su utente, chiave idutente)
POSSIEDE_PORT (table che collega UTENTE e PORTAFOGLIO key primary idutente and idport che foreign e key foreign)
PORTAFOGLIO (key primary adn foreignare idport and codazione)
AZIONI(key primary is codazione, this table contain the information of azione)
APPARTENGONO (tabella che collega AZIONI con INDICI, key primary and foreign idindice and idazione)
INDICI (idindice key primary, contiene informazioni sull'indice)
che ne dite?
potrebbero bastare queste tabelle..
esistono software che aiutano nella generazione e implementazione di database, o meglio per disegnare e progettarli su pc?
utilizzo mysql e php
Grazie
apparte che mi sembra mancare un collegamento fra azione e portafoglio, per il resto mi sembra tutto ok.
Se spieghi meglio il funzionamento dei portafogli posso darti una mano...!
A prima vista penso che potresti mettere un attributo (utente) in "portafoglio" e fare un "references" con l'id dell'utente al quale fa riferimento...
In questo modo avresti un minor spreco di spazio (in quanto elimineresti la tabella POSSIEDE_PORT) ed una maggiore rapidità nell'esecuzione delle query!
Poi dipende sempre dalle specifiche e da come intendi affrontare il problema!
Per quanto riguarda i tool per disegnare diagrammi E-R posso consigliarti questo (http://prdownloads.sourceforge.net/dia-installer/dia-setup-0.95.zip?download) si chiama "dia" ed è anche in italiano!per quanto riguarda i dbms utilizzi mysql,quindi non hai bisogno di nulla e per l'interfaccia sei ok con php!
The Incredible
24-05-2006, 19:47
pensavo di tenere la tabelle POSSIEDE_PORT dove aggiungere info, ad esepio data creazione classifica ect..
Spiegazione se riesco a darla..vediamo..
La palestra della borsa è un gioco dove poter misurare le proprie capacità di investimento in modo virtuale. Una specie di borsa simulata con soldi virtuali ma dati e resto reali.
Ogni utente che si iscrive può partecipare ad esempio a qlc torneo tipo migliore settimana mese ect..
si parte con un tot di budget..
Si può sempre usare il tutto senza competere con gli altri ma solo per verificare le proprie conoscenze e capire se si può incominciare a fare sul serio..
che ne dite?mi sono espresso in maniera decente?
The Incredible
24-05-2006, 19:52
apparte che mi sembra mancare un collegamento fra azione e portafoglio, per il resto mi sembra tutto ok.
il collegamento c'è..
PORTAFOGLIO (key primary adn foreignare idport and codazione)
codazione è chiave esterna primaria in azione
il collegamento c'è..
PORTAFOGLIO (key primary adn foreignare idport and codazione)
codazione è chiave esterna primaria in azione
ah portafoglio era la tabella di relazione, non un entita a se :)
The Incredible
25-05-2006, 07:24
l'unico problema che mi resta è dove mettere i dati di ogni giorno delle azioni?
dentro che tabella?dentro azioni mettendo come chiave primaria codice e data ora?oppure c'è un modo + furbo?
Grazie
l'unico problema che mi resta è dove mettere i dati di ogni giorno delle azioni?
dentro che tabella?dentro azioni mettendo come chiave primaria codice e data ora?oppure c'è un modo + furbo?
Grazie
se devi tenere lo storico dell'andamento(come immagino) ti conviene fare una tabella andamento_azioni, con fk_azione, come chiave il giorno e/o l'ora(dipende da che granularità vuoi) e il valore del titolo, volume di scambi, etc
The Incredible
25-05-2006, 07:39
se devi tenere lo storico dell'andamento(come immagino) ti conviene fare una tabella andamento_azioni, con fk_azione, come chiave il giorno e/o l'ora(dipende da che granularità vuoi) e il valore del titolo, volume di scambi, etc
ma non sarebbe identica ad azione?
ma non sarebbe identica ad azione?
in azione, memorizzi le azioni(codice, nome, dove sono scambiate, le info relative all'azione).
In andamento_azione memorizzi le info di azione.
In questa maniera non duplichi le informazioni "statiche" sull'azione, e la base dati è piu maneggevole.
The Incredible
25-05-2006, 07:45
ma siccome su appartengono tengo conto di quale indice fanno parte le azioni, l'unica info statica che riporterei è descrizione ora non me ne vengono altre in mente.
dici che se fosse anche se fosse solo per una voce sarebbe meglio questa soluzione?
Grazie
ma siccome su appartengono tengo conto di quale indice fanno parte le azioni, l'unica info statica che riporterei è descrizione ora non me ne vengono altre in mente.
dici che se fosse anche se fosse solo per una voce sarebbe meglio questa soluzione?
Grazie
seguendo la teoria della normalizzazione si.
ma l'entità azione, la consideri come titolo?
perche altrimenti potresti dividere le 2 cose.
una tabella per i titoli
una tabella per segnare l'indice e la borsa di appartenenza del titolo(informazione che cambia, ma non con rapidità giornaliera ;)
una per il valore dei titoli giornalieri(o con granularità piu fine), con volumi di scambio nel periodo, etc etc
sarebbe forse piu normalizzato, ne manterresti l'agilità(la possibilità che un titolo cambi indice), ma sarebbe piu complicato da gestire.
se devi tenere lo storico dell'andamento(come immagino) ti conviene fare una tabella andamento_azioni, con fk_azione, come chiave il giorno e/o l'ora(dipende da che granularità vuoi) e il valore del titolo, volume di scambi, etc
Premetto che ancora capisco a fondo cosa si vuol realizzare precisamente,cmq per quel che mi è parso di capire,in effetti per gli storici ti conviene fare una tabella a parte...
Inoltre un consiglio che posso darti è di non fare chiavi primarie composte da piu attributi (come avevi detto tra codice e data ora) potrebbere risultarti scomodo nelle query.Ti conviene lasciare come attributo chiave solo codice (casomai incrementato in modo automatico da qualche contatore) e applicare l'attributo UNIQUE su codice e data ora,in modo tale che non possano essere inserite due azioni aventi lo stesso codice,la stessa data e la stessa ora.
Spero di esserti stato di aiuto
Premetto che ancora capisco a fondo cosa si vuol realizzare precisamente,cmq per quel che mi è parso di capire,in effetti per gli storici ti conviene fare una tabella a parte...
Inoltre un consiglio che posso darti è di non fare chiavi primarie composte da piu attributi (come avevi detto tra codice e data ora) potrebbere risultarti scomodo nelle query.Ti conviene lasciare come attributo chiave solo codice (casomai incrementato in modo automatico da qualche contatore) e applicare l'attributo UNIQUE su codice e data ora,in modo tale che non possano essere inserite due azioni aventi lo stesso codice,la stessa data e la stessa ora.
Spero di esserti stato di aiuto
sono d'accordo, tranne per le fk. Se l'fk fa parte della chiave, secondo me va tenuta separata(pk = fk + attributo codice)
lnessuno
25-05-2006, 20:33
mmm... visto che l'argomento è lo stesso se vuoi sto facendo una cosa simile... se ti interessa possiamo provare a collaborare, o quantomeno una volta funzionanti potremmo unire i due progetti... ho aperto un thread qua:
puoi vedere qua una preview di ciò che sarà (ovviamente è molto incompleto)
http://toss.110mb.com/
cheddici?
The Incredible
25-05-2006, 22:13
seguendo la teoria della normalizzazione si.
ma l'entità azione, la consideri come titolo?
entità azione contiene volumi prezzo ultima trattazione ect..tutto ciò che riguarda l'azione..
una tabella per i titoli
la tabella per i titoli è azione
una tabella per segnare l'indice e la borsa di appartenenza del
questa tabella è appartengono
nel forum sulla mia sign ho messola struttura della tabella esportata con phpadmin
The Incredible
25-05-2006, 22:18
Premetto che ancora capisco a fondo cosa si vuol realizzare precisamente,
ho cercato di esporre il progetto a parole poco sopra..cmq..
dimmi pure cosa nn ti è chiaro se riesco cerco di spiegarti.
cmq per quel che mi è parso di capire,in effetti per gli storici ti conviene fare una tabella a parte...
appunto per gli storici pensavo di metterli dentro ad azione..
Inoltre un consiglio che posso darti è di non fare chiavi primarie composte da piu attributi (come avevi detto tra codice e data ora) potrebbere risultarti scomodo nelle query.Ti conviene lasciare come attributo chiave solo codice (casomai incrementato in modo automatico da qualche contatore) e applicare l'attributo UNIQUE su codice e data ora,in modo tale che non possano essere inserite due azioni aventi lo stesso codice,la stessa data e la stessa ora.
Spero di esserti stato di aiuto
ok grazie del consiglio farò così.vado a modificare..
Un altra cosa a voi esperti di database mysql...che interfaccia usata?io sto usando phpmyadmin..c'è qlc di meglio per gestire la base dati?
Grazie
The Incredible
25-05-2006, 22:29
mmm... visto che l'argomento è lo stesso se vuoi sto facendo una cosa simile... se ti interessa possiamo provare a collaborare, o quantomeno una volta funzionanti potremmo unire i due progetti... ho aperto un thread qua:
puoi vedere qua una preview di ciò che sarà (ovviamente è molto incompleto)
http://toss.110mb.com/
cheddici?
non riesco a vedere la discussione e ho provato a fare la ricerca ma il forum ha dei problemi in questo momento..
cmq per me va bene collaborare per raggiungere uno scopo comune.
lnessuno
25-05-2006, 22:34
non riesco a vedere la discussione e ho provato a fare la ricerca ma il forum ha dei problemi in questo momento..
cmq per me va bene collaborare per raggiungere uno scopo comune.
errore mio, volevo linkarti la discussione ma mi son reso conto che ti interesserebbe poco probabilmente. cmq è qua:
http://www.hwupgrade.it/forum/showthread.php?t=1208519
ora ho mandato avanti un pò la cosa, se trovo un hosting decente che supporta l'apertura di file di testo da remoto, php, mysql e i cronjob sono a cavallo :D
The Incredible
26-05-2006, 12:34
errore mio, volevo linkarti la discussione ma mi son reso conto che ti interesserebbe poco probabilmente. cmq è qua:
http://www.hwupgrade.it/forum/showthread.php?t=1208519
ora ho mandato avanti un pò la cosa, se trovo un hosting decente che supporta l'apertura di file di testo da remoto, php, mysql e i cronjob sono a cavallo :D
che sono i cronjob?
ho cercato di esporre il progetto a parole poco sopra..cmq..
dimmi pure cosa nn ti è chiaro se riesco cerco di spiegarti.
Dovresti esporre meglio a parole di cosa si occupa precisamente il tuo progetto e specificare ogni eventuale ambiguità!Quello che hai espresso secondo me è molto povero o meglio non comprensibile,per chi come me,non conosce a fondo l'argomento!Inoltre potresti specificare meglio tutti gli attributi che compongono ogni singolo "concetto".
Un altra cosa a voi esperti di database mysql...che interfaccia usata?io sto usando phpmyadmin..c'è qlc di meglio per gestire la base dati?
Grazie
Non saprei,io utilizzo firebird che ha come interfaccia "flamerobin".
Ti ho fatto notare di esporre meglio il testo a parole,perche per chi come me usa un database diverso da mysql, potrebbe non capire precisamente ciò che vorresti esporre veramente!
The Incredible
27-05-2006, 21:04
ecco il database che ho pensato..mancano due relazioni..
da portafoglio ad azione (attraverso idazione)
da azione a appartengono (attraverso idazione)
che ve ne pare?consigli critiche suggerimenti?
http://img47.imageshack.us/img47/4364/schemaer7kj.jpg (http://imageshack.us)
lnessuno
27-05-2006, 23:48
ecco il database che ho pensato..mancano due relazioni..
da portafoglio ad azione (attraverso idazione)
da azione a appartengono (attraverso idazione)
che ve ne pare?consigli critiche suggerimenti?
http://img47.imageshack.us/img47/4364/schemaer7kj.jpg (http://imageshack.us)
senti ma... posso chiederti da dove li prendi tu i dati? io ora li sto prendendo dal foglio esportato di yahoo finanza, ma non è comodissimo... non c'è un gran che diciamo.
The Incredible
28-05-2006, 12:06
senti ma... posso chiederti da dove li prendi tu i dati? io ora li sto prendendo dal foglio esportato di yahoo finanza, ma non è comodissimo... non c'è un gran che diciamo.
li prendo da yahoo..ogni giorno alla chiusura delle contrattazioni farò cosi..ma dovrei trovare anche io un modo + veloce e semplice..
lnessuno
28-05-2006, 12:26
li prendo da yahoo..ogni giorno alla chiusura delle contrattazioni farò cosi..ma dovrei trovare anche io un modo + veloce e semplice..
capit... allora se può esserti utile pensavo di farmi un dominio da utilizzare per questo scopo, possibilmente su hosting linux così sono supportati i cron job e si può impostare in modo tale da fare l'importazione dei dati ogni x tempo :p
magari sentiamoci su msn o icq, così vediamo se riusciamo ad unire i nostri sforzi...
ecco il database che ho pensato..mancano due relazioni..
da portafoglio ad azione (attraverso idazione)
da azione a appartengono (attraverso idazione)
che ve ne pare?consigli critiche suggerimenti?
http://img47.imageshack.us/img47/4364/schemaer7kj.jpg (http://imageshack.us)
Toglimi una curiosità...Ma un utente quanti portafogli può avere??Ed un portafogli puo essere di una ed una sola persona??Secondo me potresti togliere la tabella possiede_port e spostare tutto in portafoglio... Poi vedi tu!
Un'altra piccla annotazione!Giustamente hai messo (nella tabella appartengono) l'attributo indice come chiave esterna all'attributo "indice" della tabella "indici"...
Prima cosa secondo me,come ti ho gia scritto in questo post,non ti conviene fare chiavi con attributi di tipo VARCHAR,secondo me ti conviene fare un attributo codice che viene incrementato da un contatore in modo automatico ogni volta che inserisci un indice e rendere UNIQUE l'attributo "indice".
Un'altra cosa... come mai hai inserito la relazione 03??con la foreign key verso indici potresti toglierla,tutt'al piu la relazione la puoi inserire tra appartengono e azione,oppure potresti semplicemente rendere l'attributo "idazione" della tabella appartengono chiave esterna per l'attributo "codice" della tabella azione,risolvendo cosi ogni dubbio!!!
In definitiva,il mio parere è togliere tutte le relazioni presenti e far riferire gli alcuni attributi agli attributi di altre tabelle.
Spero di essermi spiegato correttamente e di aver reso l'idea!
Toglimi una sola curiosità,con che programma hai disegnato le tabelle???
The Incredible
28-05-2006, 19:22
Toglimi una curiosità...Ma un utente quanti portafogli può avere??Ed un portafogli puo essere di una ed una sola persona??
un utente può avere + portafogli..
un portafoglio può essere di una sola persona..
Secondo me potresti togliere la tabella possiede_port e spostare tutto in portafoglio... Poi vedi tu!
ma siccome una persona può avere + portafogli, non viene meglio tenerla?
Prima cosa secondo me,come ti ho gia scritto in questo post,non ti conviene fare chiavi con attributi di tipo VARCHAR,secondo me ti conviene fare un attributo codice che viene incrementato da un contatore in modo automatico ogni volta che inserisci un indice e rendere UNIQUE l'attributo "indice".
mi potresti spiegare come mai nn conviene fare chiavi varchar e conviene far chiavi dei contatori?magari anche qualche link da leggere per farmi le idee chiare.
Un'altra cosa... come mai hai inserito la relazione 03??
l'ho inserita se no non sarebbe collegate tra loro, per vedere a che indice appartiene un azione come faccio se no?
tutt'al piu la relazione la puoi inserire tra appartengono e azione,
fatto come ho scritto nell'inizio del disegno..
ecco il database che ho pensato..mancano due relazioni..
da portafoglio ad azione (attraverso idazione)
da azione a appartengono (attraverso idazione)
In definitiva,il mio parere è togliere tutte le relazioni presenti e far riferire gli alcuni attributi agli attributi di altre tabelle.
Spero di essermi spiegato correttamente e di aver reso l'idea!
Toglimi una sola curiosità,con che programma hai disegnato le tabelle???togliendo tutte le relazioni collegherei le tabelle con dei join giusto?
ho fatto il disegno con dbdesigner 4..
grazie mille per le risposte.
un utente può avere + portafogli..
un portafoglio può essere di una sola persona..
ma siccome una persona può avere + portafogli, non viene meglio tenerla?
Appunto..visto che un portafoglio puo avere una sola persona conviene inserire gli attributi di possiede_port in portafoglio!Fidati che è corretto farlo!Se una persona contiene + portafogli ovviamente il codice del portafogli cambia,quindi non vedo dov'è il problema...
mi potresti spiegare come mai nn conviene fare chiavi varchar e conviene far chiavi dei contatori?magari anche qualche link da leggere per farmi le idee chiare.
Se vuoi ti metto a disposizione una miniguida sql prodotta dal mio docente universitario...Fammi sapere se hai bisogno.Conviene far chiavi con degli interi in quanto sono piu semplici per effettuare i confronti...Con le stringhe dovresti effettuare molte operazioni prima di confrontarle (es.vedere se hanno la stessa lunghezza,confrontare parola per parola...)
l'ho inserita se no non sarebbe collegate tra loro, per vedere a che indice appartiene un azione come faccio se no?
Allora...cancellando la relazione 3 potresti dichiarare "idindice" della tabella "appartengono" come chiave esterna alla tabella "indici" in particolare all'attributo "idindici"...In questo modo quando inserisci un indice in appartengono,la base di dati in automati controlla se l'indice inserito è presente nella tabella "indici".Se esso non è presente lancia l'eccezione...
Discorso analogo per "idazione" sempre della tabella "appartengono" io farei fare tale attributo come chiave esterna alla tabella "azione"in particolare all'attributo "codice".
Dai un'occhiata qui (http://cesidio.altervista.org/borsa.doc)
Ciao ;)
The Incredible
29-05-2006, 22:37
Appunto..visto che un portafoglio puo avere una sola persona conviene inserire gli attributi di possiede_port in portafoglio!Fidati che è corretto farlo!Se una persona contiene + portafogli ovviamente il codice del portafogli cambia,quindi non vedo dov'è il problema...
guarda sbagli..siccome la tabella portafoglio conterrà tutte le azioni ripeterei le info statiche budget iniziale e data creazione per tutte le azioni..e per di più un portafoglio può essere creato senza aver ancora azioni..ma esiste ed ha una datacreazione e un budget iniziale..
Con le stringhe dovresti effettuare molte operazioni prima di confrontarle (es.vedere se hanno la stessa lunghezza,confrontare parola per parola...)
ma le stringhe alla fine saranno dei semplici codici alfanumerici
Allora...cancellando la relazione 3 potresti dichiarare "idindice" della tabella "appartengono" come chiave esterna alla tabella "indici" in particolare all'attributo "idindici"...In questo modo quando inserisci un indice in appartengono,la base di dati in automati controlla se l'indice inserito è presente nella tabella "indici".
guarda che la relazione è esattamente quello che dici tu.. :read: in appartengono idindici è indicato come FK (foreign key di indice)
Se esso non è presente lancia l'eccezione...
Discorso analogo per "idazione" sempre della tabella "appartengono" io farei fare tale attributo come chiave esterna alla tabella "azione"in particolare all'attributo "codice".
già fatto come ho scritto prima della tabella..
Dai un'occhiata qui (http://cesidio.altervista.org/borsa.doc)
ok grazie
Perry_Rhodan
30-05-2006, 19:26
per scaricare i dati da yahoo e da altri fornitori free permettetemi di consigliare il programma shareware Amiquote che potete scaricare da qui:
http://www.amibroker.com/download.html#amiquote
si tratta di un programmino molto flessibile e potente che salva i dati in formato ascii che può facilmente essere importato in altri programmi (in effetti nasce come dowloader di dati free per il programma AmiBroker).
Riguardo ai dati Yahoo ricordo che vanno usati con una certa cautela perchè spesso contengono imprecisioni, specialmente per quanto riguarda le borse non USA, i dati americani invece sono piuttosto affidabili.
Altro consiglio, con amiquote impostate parametri di scarico dati poco "aggressivi" altrimenti il server di yahoo vi blocca l'IP (crede che sia un attacco denial of service :D )
Ciao
guarda sbagli..siccome la tabella portafoglio conterrà tutte le azioni ripeterei le info statiche budget iniziale e data creazione per tutte le azioni..e per di più un portafoglio può essere creato senza aver ancora azioni..ma esiste ed ha una datacreazione e un budget iniziale..
Si,ma un portafoglio quante azioni può avere??
Ripetere il budget iniziale e la data_creazione di un portafoglio infatti è corretto se,come penso accada nella realtà,ogni portafoglio ha un proprio budget iniziale ed una data_creazione...
Tutt'al piu,sempre se ho capito cosa intendi fare,ti conviene separare le tre tabelle "utente","portafoglio","azione" e fare una tabella che ti associa tutte e tre [es. ASSOCIAZIONE (id_utente,id_portafoglio,id_azione)] dato che un portafoglio può anche non avere azioni!
Che ne pensi di questa soluzione??
ma le stringhe alla fine saranno dei semplici codici alfanumerici
Tutto dipende da come sei abituato a lavorare...
Personalmente mi trovo meglio con il codici numerici anzichè alfanumerici!!
guarda che la relazione è esattamente quello che dici tu.. :read: in appartengono idindici è indicato come FK (foreign key di indice)
Si ma id_azione (in appartengono) non è indicato come FK verso la tabella "azioni"!!!!
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.