Progettare un Db

Community IT
1

Buongiorno a tutti, mi servirebbe un aiuto, vorrei fare un’applicazione
che mi archivi gli esiti di un mercato, in pratica per ogni ora di ogni
giorno devo avare il prezzo che è uscito per diversi mercati, la mia
problema è come progettare in maniera ottimale il mio Db, la mia
intenzione era creare una tabella com un campo data e un campo market
per il tipo di mercato, poi avere un’altra tabella nella quale ci sono
24 campi, uno per ogni ora, tipo ora1, ora2, ora3, ecc…
E linkare le due tabella con una relazione uno uno.

IL problema è che non so se è progettato corretamente, ci sono delle
ottimizzazioni dafare??

Spero possiate aiutarmi grazie.

create table sections(
id int UNSIGNED NOT NULL auto_increment,
data date NOT NULL,
market varchar(20) NOT NULL,
primary key (id)
)ENGINE=InnoDB;

create table hours(
id int UNSIGNED NOT NULL auto_increment,
section_id int UNSIGNED NOT NULL,
ora1 int UNSIGNED NOT NUL,
ora2 int UNSIGNED NOT NUL,
ora3 int UNSIGNED NOT NUL,
ora4 int UNSIGNED NOT NUL,
…
…
…
constraint fk_hours_section foreign key (section_id) references
sections(id),
primary key (id)
)ENGINE=InnoDB;

2

ciao Michele,

sei un pelino off-topic, qui si dovrebbe parlare di argomenti
correlati a ruby :stuck_out_tongue:

A.

Il 02/02/2012 17:04, michele boscolo ha scritto:

3

Lo so ma lo vorrei realizzare in Ruby on Rails, e dato che seguo solo
questo forum, ho preferito chiederlo qui :slight_smile:
Spero che qualcuno mi possa aiutare lo stesso.

4

Mi accordo agli altri. Utilizzando 24 colonne una per ora il dato non
normalizzato; non che sia di per se un male: molti software
denormalizzano
i dati per rendere l’interrogazione dal database pi veloce, anche se in
questo la scelta di denormalizzare i dati non mi sembra essere stata
presa
valutandone i pro e contro.

Ciao
Stefano

2012/2/3 Paolo M. [email protected]

5

Leggermente offtopic, ma già che ci siamo…

Io creerei una tabella con market, data, ora (due campi diversi o uno,
dipende) e prezzo.
24 colonne una per ora mi pare molto faticoso e molto rigido. E se poi
ci sarà bisogno di aumentare la risoluzione?

Per decidere la struttura pensa anche a che query ci dovrai fare, ad
esempio per elaborare delle statistiche. Le select a 24 campi sembrano
inutilmente difficili.

La media dei prezzi del giorno fatta così pare semplice:

select avg(prezzo) from tabella group by data;

che dovendo sommare 24 campi (non garantisco che quella query sia sql
corretto, ma ci siamo intesi). Però è anche possibile che esplicitando i
campi sia più veloce. Se prevedessi problemi di performance devi subito
ottimizzare lo schema per quelle anche a costo di dover far salti
mortali con l’sql.

Erano i miei 2 centesimi…
Paolo

6

Ciao ti consiglio di dare un’occhiata a questi links e il resto
verr da se… :

  1. Active Record Associations — Ruby on Rails Guides

http://www.methack.it/devblog/database/metodi-di-progettazione-di-una-base-di-dati-relazionale/
3.

Have Fun!

RD

Il giorno 02/feb/2012, alle ore 17.04, michele boscolo ha scritto:

7

Michele,

Crea il db della tua app mano a mano che scrivi l’app, usando le
migration:
Active Record Migrations — Ruby on Rails Guides.

E progetta il db “the rails way”, viene tutto pi facile.

Ciao,

Matteo

8

Grazzie a tutti comunque ho già risolto, mi sono prese un libro su SQL,
e ho fatto un full immersion, che mi ha chiarito parecchio le idee.

Ciao.

9

+1

Partire dalle tabelle una via difficile e oscura, se non completamente
sbagliata (a meno di casi particolari).
Bisogna partire dalle viste, il che ti porta a chiederti come reperire i
dati che ti servono (controller), il che ti porta a progettare di
conseguenza il tuo modello, e infine a creare la tabella.
Alla fine probabilmente scoprirai che mancher qualcosa, e la aggiungerai
in corso d’opera, iterando man mano.

Il giorno 10 febbraio 2012 11:14, Matteo C.
[email protected]ha scritto: