Vantaggi e svantaggi della normalizzazione
Oggi torniamo ancora una volta, ma stavolta più in dettaglio, su un argomento importante: vantaggi e svantaggi della normalizzazione, così capirai meglio come queste idee si applicano nella vita reale. Quindi, allaccia le cinture — si parte!
Eliminazione della ridondanza dei dati
Quando i dati in una tabella non sono normalizzati, puoi trovarti con le stesse informazioni duplicate in diverse righe. Per esempio, in una tabella degli ordini potresti avere lo stesso indirizzo cliente ripetuto per ogni ordine. La normalizzazione elimina queste duplicazioni, spostando i dati comuni in tabelle separate.
Esempio:
-- Prima della normalizzazione
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT,
order_date DATE
);
-- Dopo la normalizzazione
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE
);Perché è importante? Meno dati duplicati significa meno possibilità di errori. Se l'indirizzo del cliente cambia, devi aggiornarlo solo in un posto.
Garantire l'integrità dei dati
Quando i dati sono divisi in tabelle logiche, è facile gestire le loro relazioni. Usare le chiavi esterne aiuta a mantenere l'integrità dei dati in automatico. Per esempio, non puoi cancellare per sbaglio un cliente a cui sono collegati ordini nella tabella degli ordini.
Esempio:
-- La chiave esterna garantisce che cancellando un cliente si cancellano anche gli ordini collegati
ALTER TABLE orders
ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)
ON DELETE CASCADE;
Puoi stare tranquillo che la struttura del database non permetterà la comparsa di dati "orfani".
Aggiornamenti più semplici
Quando il tuo database è normalizzato, gli aggiornamenti diventano facili e meno soggetti a errori. Torniamo all'esempio dei clienti — se un cliente cambia indirizzo, aggiorni il suo record solo in una tabella. In tabelle non normalizzate, è probabile che ti dimentichi di aggiornare l'indirizzo in alcune righe, portando a dati incoerenti.
Minimizzazione delle anomalie
Anomalie di inserimento: in una tabella non normalizzata puoi trovarti nella situazione in cui non puoi aggiungere un record senza informazioni inutili. Per esempio, non puoi aggiungere un ordine finché non conosci il nome del cliente.
Anomalie di aggiornamento: possono succedere errori durante l'aggiornamento dei dati. Per esempio, cambiando il nome del cliente in una riga, in un'altra riga potrebbe rimanere quello vecchio.
Anomalie di cancellazione: cancellare un record può portare alla perdita di informazioni importanti. Per esempio, cancellando un ordine si cancella anche il nome del cliente, se questi dati sono nella stessa tabella.
Riduzione del volume dei dati
La normalizzazione spesso riduce la dimensione del database, perché elimina la duplicazione dei dati. Questo è un aspetto importante quando si devono gestire grandi quantità di informazioni.
Svantaggi della normalizzazione
1. Struttura del database più complessa
Col tempo, la normalizzazione può portare a una struttura del database complicata, fatta di migliaia (!) di tabelle collegate. In questi casi, per ottenere dati che prima stavano in una sola tabella, devi scrivere query SQL complesse con molte join (JOIN).
Esempio di complessità:
-- Query per ottenere info sugli ordini con dettagli su prodotti e categorie
SELECT
o.order_id,
o.order_date,
c.customer_name,
p.product_name,
cat.category_name,
oi.quantity,
oi.unit_price
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories cat ON p.category_id = cat.category_id;
Se il numero di tabelle e relazioni cresce, il tempo di esecuzione delle query può aumentare parecchio.
2. Prestazioni ridotte con join frequenti
Spesso fare join tra tabelle (JOIN) può essere pesante, soprattutto se le tabelle sono grandi e senza indici. Nei sistemi analitici, dove le query devono lavorare su milioni di righe, la normalizzazione porta a grossi rallentamenti nelle performance.
3. Bisogno di operazioni extra per la denormalizzazione
Se la struttura normalizzata del database viene usata per scopi analitici, spesso bisogna denormalizzare temporaneamente per velocizzare le query analitiche. Questo può voler dire creare viste (VIEW) o tabelle di aggregazione.
Esempio:
-- Vista denormalizzata per l'analisi
CREATE VIEW orders_with_customers AS
SELECT
o.order_id,
o.order_date,
c.customer_name,
c.customer_address
FROM
orders o
JOIN
customers c ON o.customer_id = c.customer_id;
4. Barriera d'ingresso alta
Per chi è alle prime armi, la normalizzazione può sembrare difficile. Invece di una tabella con tutti i dati, devi lavorare con più tabelle e capire come sono collegate. Questo può rallentare lo sviluppo, soprattutto se il team non ha molta esperienza con i database.
5. A volte la ridondanza è utile
Nei progetti reali, a volte conviene mantenere dati ridondanti per migliorare le performance. Per esempio, se l'app usa spesso dati che si possono ottenere solo con join complessi, è meglio tenerli in una sola tabella.
GO TO FULL VERSION