Originariamente inviato da Stibbert
La soluzione con due tabelle mi sembra la più performante (e più facile da gestire).
è il contrario

Originariamente inviato da Stibbert
X Bomberdini
Il problema è questo: Se scrivi una fattura e copi i valori del cliente (o dell'articolo) rendi il tuo database enorme inutilmente, perchè non è normalizzato.
Se fai una relazione con il cliente, e poi questo cambia indirizzo, nella fattura ti appaiono dati modificati che la rendono una fattura falsa...
Quindi devi creare delle tabelle intermedie nelle quali salvi tutte le modifiche nel corso degli anni (record duplicati).
Ma va là.
Altro che tabelle intermedie.
I dati del cliente vanno nella fattura, per il semplice fatto che (dal punto di vista logico) sono attributi della fattura medesima.
Quindi è corretto, logicamente, scrivere i dati lì, oltre che fiscalmente necessario.
Senza parlare poi della velocità enormemente maggiore di uno schema siffatto (con la riduzione degli inutili join)
Fine del discorso per quanto riguarda le fatture, tanto se lo approfondisco vengo rimbrottato come al solito (per inciso è la domanda classica per stabilire se il novizio capisce cosa significa "normalizzare" o si limita ad applicare le regolette somministrategli, partendo lancia in resta ciecamente).

Con riferimento invece al "database enorme", vado per le spicce.
E' una sciocchezza. L'idea di normalizzazione di Boyce, nata negli anni '70, era in un mondo di computer con 2KByte di memoria e supporti magnetici a nuclei di ferrite (quando andava bene), dove un database con più di 2^16 righe era già un grande problema per la gestione di valori di più di 2 byte.

Oggi un computer da 500 euro ha le capacità di elaborazioni sufficienti per l' "enorme database" di una multinazionale.
In mano a gente preparata basta un telefono.