Progettare un Db

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;

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:

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.

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.

http://en.wikipedia.org/wiki/Database_normalization

Ciao
Stefano

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

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

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

  1. http://guides.rubyonrails.org/association_basics.html

http://www.methack.it/devblog/database/metodi-di-progettazione-di-una-base-di-dati-relazionale/
3.
http://www.packtpub.com/article/designing-creating-database-tables-in-ruby-on-rails

Have Fun!

RD

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

Michele,

Crea il db della tua app mano a mano che scrivi l’app, usando le
migration:
http://guides.rubyonrails.org/migrations.html.

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

Ciao,

Matteo

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.

+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:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs