Ciao.
Vorrei implementare nel mio progetto la funzione di aggiornamento nel tempo dell'archivio clienti.
Mi sono informato e ho visto che vengono utilizzate due strategie:
1) Utilizzare una sola tabella con una relazione "a diamante" (così mi hanno detto che si chiama).
2) Utilizzare una tabella "clienti" e una "storia". Al momento della variazione copiare i valori da clienti e storia in un nuovo record.
Non ho esperienza, quindi non so cosa è meglio...
Mi potete aiutare voi?
Grazie
Ciao,
Puoi spiegare meglio cosa vuoi fare?
Non si può risolvere un problema usando lo stesso modo di pensare che ha creato quel problema.
Albert Einstein
Siate Affamati, siate Folli, siate Onesti e siate Generosi
Io tipicamente non utilizzo una sola tabella in quanto prevede di aggiungere ulteriori informazioni che nn sono direttamente collegate a quella entità, in secondo luogo prevede che tutte le interrogazioni su tale tabella debano filtrare i dati "Storici".
Tipicamente creo una tabella speculare con l'aggiunta delle nuove colonne storiche (PRG_VRZ,DATA_VARIZIONE,TIPO_VARIAZIONE,UTENTE etc...) e definisco 2 trigger sulla tabella per effettuare le operazioni di inserimento e aggiornamento della tabella storica.
In questo modo le interrogazioni già sviluppate sulla tabella non devono essere modificate e soprattuto non vado ad "appesantire" ulteriormente la tabella di cui stiamo effettuando la storicizzazione.
X Francesco Muia
Grazie. Anche io ero arrivato alla tua conclusione, ma siccome i "professionisti" che ho consultato usano una sola tabella mi erano venuti dei dubbi...
La soluzione con due tabelle mi sembra la più performante (e più facile da gestire).
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 (o un prezzo viene aggiornato), 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).
Originariamente inviato da Stibbert
La soluzione con due tabelle mi sembra la più performante (e più facile da gestire).è il contrario
Ma va là.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).
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.
Per tabella intermedia intendevo quella storica, con i dati che non vengono più modificati.
Se mi collego a quella, sono sicuro che non si alterano con il tempo.
Indubbiamente potere evitare i join semplifica la gestione dell'archivio dal lato del programmatore.
P.S. Un mio amico ha lavorato sul db di una multinazionale del lusso.
Con un SAP faceva delle query in sudamerica di mattina, poi usciva e tornava la sera a vedere che set di dati era uscito...
Non mi sembra fosse una cosa molto veloce!
E' il contrario: stai complicando inutilmente, e rallentando, una situazione semplice.Originariamente inviato da Stibbert
Per tabella intermedia intendevo quella storica, con i dati che non vengono più modificati.
Se mi collego a quella, sono sicuro che non si alterano con il tempo.
Indubbiamente potere evitare i join semplifica la gestione dell'archivio dal lato del programmatore.
Come menarsi sui maroni così, tanto per fare
Pensa che per me una query sul database di una multinazionale, se impiega più di 3 secondi, è sbagliata.P.S. Un mio amico ha lavorato sul db di una multinazionale del lusso.
Con un SAP faceva delle query in sudamerica di mattina, poi usciva e tornava la sera a vedere che set di dati era uscito...
Non mi sembra fosse una cosa molto veloce!
Riguardo a SAP... vabbè chiudo subito il discorso senza neppure aprirlo, ci saranno tanti che lo conoscono benissimo.
PS I documenti fiscali, ovviamente, non vengono mantenuti in formato "database", bensì... cartaceo, ovvero vanno conservati i relativi PDF, perchè le eventuali ri-stampe potrebbero essere diverse.
Nei casi importanti si memorizzano i PDF con dentro le immagini raster
"E' il contrario: stai complicando inutilmente, e rallentando, una situazione semplice.
Come menarsi sui maroni così, tanto per fare".
Lo so, te l'ho anche detto, e ti do ragione!
Tutte le volte che devo aggiungere un'ulteriore tabella a un form mi prende male...
Per il tempo della query, dipende da quanti milioni di record hai e da che calcoli ci fai sopra...
(Questo io non te lo so dire).
hai fatto bene a specificarlo, perché a leggere quello che avevi già scritto sembrava il contrario (per le menti a basso tenore di neuroni come la miaOriginariamente inviato da franzauker2.0
PS I documenti fiscali, ovviamente, non vengono mantenuti in formato "database", bensì... cartaceo, ovvero vanno conservati i relativi PDF, perchè le eventuali ri-stampe potrebbero essere diverse.)
Non mi occupo spesso di queste cose, però mi risulta che la prassi è mantenere, ovviamente, sia i documenti "database", per consentire ristampe rapide, sia i documenti fiscali effettivamente contabilizzati (quelli di carta, per intenderci).Originariamente inviato da optime
hai fatto bene a specificarlo, perché a leggere quello che avevi già scritto sembrava il contrario (per le menti a basso tenore di neuroni come la mia
In un mondo ideale coincidono, ma ciò non è sempre detto, poichè quello che si usa tipicamente (un report editor di qualche genere) non sempre, nelle sue varie release ed anche con sistemi operativi diversi, è in grado di ricreare in maniera perfetta il medesimo documento in fase di ristampa.
Ho letto su topolino che questo non sempre è considerato negativamente, soprattutto perchè la stampa poi effettiva a sua volta soffre delle differenze di stampanti (esempio: autoridimensionamento dei PDF a seconda dei margini).
Comunque l'uomo saggio si tiene i PDF, a scanso di equivoci.
O forse no, dipende, non so.
Permessi di invio
Rispondi quotando