Quando ho iniziato il mio primo progetto con un database relazionale, ho creato le tabelle seguendo la logica del momento. Nessuna normalizzazione, nessun diagramma, solo colonne aggiunte man mano che servivano.
Il momento in cui il problema e diventato visibile
Dopo sei mesi, il cliente ha chiesto di associare piu indirizzi a un singolo utente. Nel mio schema, lindirizzo era una colonna VARCHAR nella tabella utenti. Modificare quella struttura significava riscrivere 14 query distribuite su 6 file diversi.
Il costo di un refactoring cresce in modo non lineare con il tempo trascorso. Correggere uno schema dopo sei mesi e dieci volte piu costoso che farlo alla settimana uno.
Cosa avrei dovuto fare prima
- Disegnare un diagramma entita-relazione anche su carta prima di scrivere la prima CREATE TABLE
- Applicare almeno la terza forma normale alle entita principali
- Discutere i requisiti futuri con il cliente prima di iniziare, non dopo
Oggi dedico la prima parte di ogni giornata lavorativa a rivedere lo schema esistente prima di aggiungere funzionalita. Per chi studia database programming, la fase di progettazione non e opzionale. Anche consultare documentazione tecnica in formato statico, ad esempio tramite pdf24 download, aiuta a tenere i riferimenti accessibili senza dipendere dalla connessione.