In un database è meglio risparmiare sul numero di tabelle oppure meglio abbondare?

[American]

Salve, vorrei provi un quesito semplice ma su cui spesso mi vengono molti dubbi..
In pratica mi trovo talvolta in situazioni in cui posso giostrarmi all'interno delle tabelle di un database evitando di creare tabelle separate laddove sarebbe consigliato se non altro per avere una struttura più chiara del progetto.
In questo modo riesco a risparmiare sul numero di tabelle, mi ritrovo però a costretto a scrivere query contorte secondo una mia "logica personale" (il che rende difficoltoso un eventuale lavoro di manutenzione).
Ad ogni modo secondo voi risparmiare sul numero di tabelle porta reali vantaggi in termini di performance oppure meglio abbondare cercando di privilegiare sempre e comunque la chiarezza strutturale del DB?

[badaze]

Facci qualche esempio.

Secondo me un db ben fatto è anche economico in termini di spazio disco, prestazioni e sviluppo. Se per esempio hai una tabella "articoli ordinati" e dentro hai anche tutti i dati del cliente sbagli di grosso perché potresti risparmiare spazio disco e prestazioni creando una tabella "testata ordine". Sempre con quella tabella se ti sei detto "non avro' mai ordini di più di 10 articoli" allora mi creo i campi "articolo 1" "quantità 1" "prezzo 1" etc fino a "articolo 10" "quantità 10" "prezzo 10" etc (esempio vissuto) non sbagli di grosso, sei incompetente.

Se in una tabella hai molti campi forse puoi dividerla in unità logiche che conterranno insiemi di dati coerenti. Anni fa ho lavorato su un progetto con alcune tabelle che avevano più di 150 campi. Il che ci faceva leggere molti dati per utilizzare (quasi) sempre gli stessi. Quindi se avessimo spartito le tabelle in unità coerenti avremmo avuto più tabelle ma avremmo avuto migliori prestazioni evitando di leggere dati utilizzati una volta su 10 o 20. E' vero che adesso con le prestazioni dei materiali il bisogno si fa meno sentire. Comunque.

Nella mia firma, è scritto "Non serve a nulla ottimizzare qualcosa che non funziona" e questo vale anche per la struttura del db. Le cose chiare sono sempre più facili da spiegare, da capire, da analizzare, da sviluppare, da documentare, da testare e da mantenere.

Non sbagli mai scegliendo la via della chiarezza (quasi quasi me l'aggiungo nella firma ).

[optime]

né risparmiare né abbondare: vanno usate quelle giuste

[American]

Facci qualche esempio.

Intanto grazie per la risposta.
La mia situazione è questa: ipotizziamo una gestione di magazzino con carichi (rifornimenti) e scarichi (vendite) degli articoli.

Ho creato una tabella "magazzino" in cui sono memorizzate entrambe le azioni
Snapshot_3.jpg

Nella fattispecie, quando si tratta di un carico, mi ritrovo con una situazione del genere:
Snapshot_4.jpg

Nel caso di uno scarico, la situazione è questa:
Snapshot_5.jpg

(da notare che idTipologiaMovimento è una chiave esterna ad una tabella in cui sono memorizzati i due tipo di movimento possibili, 1 è l'id relativo al carico, 2 allo scarico)
A seconda del tipo di movimento, insomma, restano NULL alcune colonne piuttosto che altre. Da notare che nel caso dello scarico c'è il riferimento al codiceOrdine, che è un collegamento 1 a molti verso la tabella ordini dalla quale prelevo i dettagli relativi ad un acquisto (id prodotti, relativa quantità e prezzo).
Concettualmente ordini dovrebbe essere ok, il mio dubbio è unicamente nel calderone che ho creato in magazzino in cui ho messo sia i carichi che gli scarichi laddove potrei creare tabelle distinte.

Allo stato attuale mettiamo che io voglia prelevare tutti gli articoli e calcolarne la disponibilità (il numero di pezzi rimanenti) in base ai carichi e gli scarichi, esce una cosa del genere:

SELECT *, 
 SUM( IF(magazzino.idTipologiaMovimento=2, -magazzino.quantita, magazzino.quantita) - IFNULL(ordini.quantita,0) ) AS disponibilita
FROM catalogo
JOIN articoli ON catalogo.Articoli_IDArticoli=articoli.ID
JOIN categorie ON categorie.ID=articoli.Categoria_IDCategoria
JOIN magazzino ON magazzino.idArticolo=articoli.ID
LEFT JOIN ordini on (magazzino.idArticolo=ordini.idArticolo AND idTipologiaMovimento=2) 

Il progetto funziona, ma mi rendo conto che è poco intuitivo come struttura

[badaze]

Infatti ti sei risposto. Se cominici a dover fare delle cose contorte significa che sbagli.

Cosa vuoi di preciso ?

[American]

Niente chiedevo se conviene lasciare la struttura così com'è oppure "scompattarla" in modo da renderla più chiara
In linea generale, quando ci sono colonne che so a priori saranno NULL in determinati casi (nell'esempio, idUtente, codiceOrdine e quantità devono restare per forza di cose NULL quando si tratta di un carico, viceversa nel caso dello scarico resteranno NULL altre colonne), vuol dire che qualcosa sto sbagliando nell'approccio? Almeno questa è la mia impressione

[badaze]

Secondo te, stock e ordine sono le stesse cose ? Nel portafogli non andresti a mettere le posate anche se ci stanno dentro.

Ho visto che mancava una parola nella mia domanda di prima.

Cosa vuoi fare di preciso ? E' per un sito o solo per apprendimento ?

[American]

no è per scopo didattico.

Bhe stock e ordine non sono la stessa cosa, ma ero partito con la logica del magazzino inteso come crocevia per carichi e scarichi (quindi c'è il senso logico). Per questo avevo messo tutto nella stessa tabella. L'ordine poi è una CONSEGUENZA dello scarico, difatti sta in tutt'altra tabella.

[badaze]

No. È lo scarico ad essere una conseguenza dell'ordine. Un ordine puo' essere cancellato.
Di più, quando scarichi, la merce non è più in magazzino.

[American]

No. È lo scarico ad essere una conseguenza dell'ordine. Un ordine puo' essere cancellato.
Di più, quando scarichi, la merce non è più in magazzino.

se un ordine viene cancellato ovviamente viene tolto anche il record dal magazzino avente quello stesso codiceOrdine. Senza contare che pure non forzassi questo comportamento nel momento in cui nella query vado a fare il LEFT JOIN non trova nulla quindi di conseguenza pure lasciassi la referenza dello scarico in magazzino non riscontrerei nulla di anomalo.

Cmq in definitiva mi consigli di fare tabelle distinte? Quindi avrei:
tabella carico
tabella scarico (a sua volta utilizzata sia per gli ordini normali -aventi quindi un codice e un idAcquirente- che per operazioni generiche, ad esempio, un articolo è stato venduto al dettaglio per cui devo semplicemente "annotarlo" nel DB senza dettagli aggiuntivi).