Strategia per "Storico"

di il
1 risposte

Strategia per "Storico"

Ciao a tutti.
Probabilmente (anzi sicuramente) è solo una pippa mentale....
Mi hanno proposto di gestire il magazzino del nostro motoclub (gadget vari, insomma), e in attesa di prendere una decisione definitiva, mi stavo inventando un piccolo DB di gestione (se l'incarico andrà a qualcun altro si troverà il gestionale bello e fatto)
Sto definendo un pò la struttura delle tabelle, e fra queste credo sarebbe una sana cosa gestire anche lo storico.
In linea di massima, i gadget vanno movimentati solo in 2 occasioni: qualche sede li richiede (e quindi è una cessione - a favore dei soci), in occasione dei motoraduni si mette la bancarella (e quindi è una vendita - a terzi).
Ero indeciso se stabilire una so la tabella Storico o se crearne 2, uno per le cessioni e uno per le vendite.
Di base i dati sono esattamente gli stessi: nel caso di una tabella unica, inserirei un campo SI/NO per distinguere i 2 tipi, mentre nel caso di 2 tabelle tabelle ovviamente ognuna avrebbe i suoi record.
La cosa più logica è una tabella unica, filtrando i dati in base al campo SI/NO, ma (e questa è la pippa mentale), ragionando sul numero di record immagazzinabili (che è pur notevole) in un ottica futura varrebbe la pena stabilire 2 tabelle, in modo che il momento di "massimo numero di record possibile" sia allontanato il più possibile?

1 Risposte

  • Re: Strategia per "Storico"

    Jocman ha scritto:


    La cosa più logica è una tabella unica, filtrando i dati in base al campo SI/NO, ma (e questa è la pippa mentale), ragionando sul numero di record immagazzinabili (che è pur notevole) in un ottica futura varrebbe la pena stabilire 2 tabelle, in modo che il momento di "massimo numero di record possibile" sia allontanato il più possibile?
    Permettimi la battuta : fatti prima una pippa reale ... dopo ... comprenderai che avere solo 1 tabella è molto meglio.
    Ovviamente ti serve poter gestire il tipo record e quindi ti occorre un campo aggiuntivo. Tu hai identificato un bool per gestire solo 2 tipi record, io ti consiglierei di utilizzare un campo numerico (byte/int) per poter gestire in futuro diversi tipi records.

    Se pensi che la base dati realizzata in Access possa avere problemi di dimensioni (cerca quali sono i limiti ... mi sembra che il DB debba essere inferiore a 2 GB ma vado a memoria) allora punta direttamente ad un vero RDBMS ma sempre con una sola tabella. Per capire se puoi avere dei problemi di dimensioni, dividi la dimensione massima del DB per la lunghezza in byte di un record della tabella : indicativamente saprai quanti records puoi gestire ...

    Giusto per chiarezza : la normalizzazione dei dati prevede che si utilizzi solo una tabella (oltremodo è banale estrarre i records in funzione del tipo record) ciò non toglie che, possano esistere delle situazioni nelle quali sia ragionevole separare le tabelle (pagando il prezzo della complicazione per estrarre i dati : come minimo 2 query distinte) ma sinceramente non mi sembra che sia questo il caso. Una casistica banale potrebbe essere la gestione di dati in maniera separata da 2 sedi distinte e con la ulteriore implicazione che le sedi non debbano vedere i dati altrui (avere 2 tabelle separate permette di gestire più facilmente gli accessi ai dati) ...
Devi accedere o registrarti per scrivere nel forum
1 risposte