Forum: Italian Ruby user group 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 :P

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 :)
Spero che qualcuno mi possa aiutare lo stesso.

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

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 Montrasio <paolo@paolomontrasio.com>

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

1. http://guides.rubyonrails.org/association_basics.html
2. 
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

+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 Collina
<matteo.collina@gmail.com>ha scritto:

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.