Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Le convenzioni e la struttura del database

I primi passi per la costruzione di un'applicazione: stabilire gli oggetti del modello, la nomenclatura, le tabelle del database
I primi passi per la costruzione di un'applicazione: stabilire gli oggetti del modello, la nomenclatura, le tabelle del database
Link copiato negli appunti

Per osservare più da vicino il funzionamento di questo ambiente realizzeremo un'applicazione non troppo complessa ma con dei punti interessanti, ovvero un semplice Forum che permetta di creare nuovi argomenti di discussione, di aggiungere dei messaggi e di permettere agli utenti di registrarsi ed effettuare il login.

Il primo passo da fare è stabilire quali sono gli oggetti del modello. Abbiamo ovviamente necessità di avere delle entità che rappresentino i messaggi, quindi creeremo una tabella messages. Ogni messaggio dovrà appartenere ad un determinato topic, per cui la nostra seconda tabella sarà appunto topics. Infine, per identificare chi invia i messaggi creeremo una tabella authors

Due parole sulla nomenclatura: come abbiamo già detto, Rails preferisce le convenzioni alle configurazioni, e quindi cerca di evitare allo sviluppatore il peso di dover specificare l'associazione tra tabelle e classi. Ovviamente però, ActiveRecord, la libreria che gestisce il database, deve avere un modo per capire da solo questa relazione, e questo modo è la lingua inglese. 

Infatti, per far sì che ActiveRecord trovi da solo le tabelle, è sufficiente che esse siano chiamate con il plurale del nome della classe e che siano scritte in minuscolo. La tabella messages sarà dunque mappata sulla classe Message, authors su Author e topics su Topic. Il meccanismo di ActiveRecord che si occupa di questa conversione è molto più intelligente di quel che potrebbe pensare, e ad esempio è in grado di capire che il plurale di "person" è "people" o che il plurale di "status" è "statuses".

Se questa convenzione non vi piace potete, come sempre, non seguirla, a patto di specificare esplicitamente il nome delle tabelle all'interno della classe, guardate la documentazione di ActiveRecord per maggiori dettagli.  Per ogni autore ci interessa mantenere informazioni sul nickname e sulla password. Un topic avrà un titolo ed un campo che indica quando è stato aggiornato l'ultima volta e un messaggio avrà un corpo e dei riferimenti al proprio autore ed al proprio topic.  Il DBMS che utilizzeremo in questo esempio è MySQL perché è quello più comune ed è disponibile con InstantRails, ma il codice di definizione delle tabelle per altri non cambia molto da questo:

CREATE DATABASE hforum_development;

CREATE TABLE messages (
 id int(11) NOT NULL AUTO_INCREMENT,
 body text NOT NULL,
 created_at DATETIME NOT NULL,
 author_id int(11) NOT NULL REFERENCES authors (id),
 topic_id int(11) NOT NULL REFERENCES topics (id),
 PRIMARY KEY (id)
);
       
CREATE TABLE authors (
 id INT NOT NULL AUTO_INCREMENT ,
 name VARCHAR( 20 ) NOT NULL ,
 password VARCHAR( 40 ) NOT NULL ,
 PRIMARY KEY ( id )
);

CREATE TABLE topics (
 id int(11) NOT NULL AUTO_INCREMENT,
 title varchar(60) NOT NULL,
 updated_at DATETIME NOT NULL,
 PRIMARY KEY (id)
);

Di nuovo una nota sui nomi: per default, le foreign key dovrebbero essere indicate come nometabella_id; updated_at, rappresenta invece uno degli attributi speciali che vengono gestiti in automatico da ActiveRecord, e che contiene un timestamp dell'ultimo accesso all'oggetto. Gli attributi speciali relativi al tempo sono created_at/created_on e updated_at/updated_on: i primi due registrano la creazione di un oggetto, mentre i secondi l'aggiornamento. La differenza del suffisso indica se essi sono di tipo DATE o DATETIME, per ricordarlo basta tradurre in italiano come creati "il" o creati "alle".


Ti consigliamo anche