# Progettare un Db **URL:** \ **Category:** IT\ **Created:** [February 2, 2012, 5:04pm UTC](https://www.ruby-forum.com/t/progettare-un-db/216367 "2012-02-02T17:04:49Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [February 2, 2012, 5:04pm UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/1 "2012-02-02T17:04:49Z")
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; ---
**Author:** ![barbz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dbc845/32.png) [@barbz](https://www.ruby-forum.com/u/barbz)\ **Post date:** [February 2, 2012, 6:23pm UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/2 "2012-02-02T18:23:22Z")
ciao Michele, sei un _pelino_ off-topic, qui si dovrebbe parlare di argomenti correlati a ruby 😛 A. Il 02/02/2012 17:04, michele boscolo ha scritto: ---
**Author:** ![barbz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dbc845/32.png) [@barbz](https://www.ruby-forum.com/u/barbz)\ **Post date:** [February 2, 2012, 6:43pm UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/3 "2012-02-02T18:43:13Z")
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. ---
**Author:** ![barbz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dbc845/32.png) [@barbz](https://www.ruby-forum.com/u/barbz)\ **Post date:** [February 3, 2012, 5:20pm UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/4 "2012-02-03T17:20:45Z")
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. > **[Database normalization](https://en.wikipedia.org/wiki/Database_normalization)** > > Database normalization or database normalisation (see spelling differences) is the process of structuring a relational database in accordance with a series of so-called normal forms in order to reduce data redundancy and improve data integrity. It was first proposed by British computer scientist Edgar F. Codd as part of his relational model. > Normalization entails organizing the columns (attributes) and tables (relations) of a database to ensure that their dependencies are properly enforced by... Ciao Stefano 2012/2/3 Paolo M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![barbz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dbc845/32.png) [@barbz](https://www.ruby-forum.com/u/barbz)\ **Post date:** [February 3, 2012, 4:12pm UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/5 "2012-02-03T16:12:20Z")
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 ---
**Author:** ![barbz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dbc845/32.png) [@barbz](https://www.ruby-forum.com/u/barbz)\ **Post date:** [February 4, 2012, 2:47pm UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/6 "2012-02-04T14:47:47Z")
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://guides.rubyonrails.org/association_basics.html) 2. [http://www.methack.it/devblog/database/metodi-di-progettazione-di-una-base-di-dati-relazionale/](http://www.methack.it/devblog/database/metodi-di-progettazione-di-una-base-di-dati-relazionale/) 3. > **[Search | Packt Subscription](https://subscription.packtpub.com/search?query=designing%20creating%20database%20tables%20in%20ruby%20on%20rails)** > > Search over 7,500 Programming & Development eBooks and videos to advance your IT skills, including Web Development, Application Development and Networking Have Fun! RD Il giorno 02/feb/2012, alle ore 17.04, michele boscolo ha scritto: ---
**Author:** ![barbz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dbc845/32.png) [@barbz](https://www.ruby-forum.com/u/barbz)\ **Post date:** [February 10, 2012, 11:15am UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/7 "2012-02-10T11:15:12Z")
Michele, Crea il db della tua app mano a mano che scrivi l’app, usando le migration: [Active Record Migrations — Ruby on Rails Guides](http://guides.rubyonrails.org/migrations.html). E progetta il db “the rails way”, viene tutto pi facile. Ciao, Matteo ---
**Author:** ![barbz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dbc845/32.png) [@barbz](https://www.ruby-forum.com/u/barbz)\ **Post date:** [February 20, 2012, 1:00pm UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/8 "2012-02-20T13:00:10Z")
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. ---
**Author:** ![barbz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/dbc845/32.png) [@barbz](https://www.ruby-forum.com/u/barbz)\ **Post date:** [February 10, 2012, 11:41am UTC](https://www.ruby-forum.com/t/progettare-un-db/216367/9 "2012-02-10T11:41:59Z")
+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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)ha scritto: