Newsgroup: it.comp.lang.visual-basic
Titolo: Vorrei un cosiglio da tutti voi [LUNGO]

So che probabilmente su questa domanda molti avranno opinioni differenti.
La cosa triste e che neanche io so cosa fare quindi vorrei vedere cosa dice
la maggioranza!
Il problema è questo:
Ho un gestionale che gestisce in toto la distribuzione di prodotti (nello
specifico calzature).
Tale programma contiene naturalmente una lista di articoli (con una miriade
di informazioni su ogni articolo tipo colore, pellame, riporto, forma,
fondo, suola, tacco, chiusura, stile, produttore, fotografia etc etc)
Naturalmente dal programma è possibile emettere degli ordini per i propri
clienti.
Emettendo l'ordine si presentano due possibilità (se ce ne una terza non mi
interessa... dovrei rifare tutto!!!)
1) in quella che sarà la tabella dell'ordine (scusatemi se non scrivo i
termini precisi) vado a salvare i dati dell'ordine + i riferimenti
all'articolo ordinato (ossia solo l'id corrispondente della tbarticoli
oppure il numero articolo). In questo modo quando vado a visualizzare
l'ordine vado a
ripescarmi i dati dell'articolo ordinato non dalla tbordine ma dalla
tbarticoli.
oppure
2) nella tabella dell'ordine salvo i dati dell'ordine + tutti i dati
dell'articolo. in questo modo quando vado a visualizzare l'ordine tutti i
dati sono già disponibili con la sola query sulla tbordine, e non ho bisogno
di interrogare la tbarticoli
Ognuno di questi due metodi ha i suoi vantaggi-svantaggi ma in particolar
modo uno:
se io oggi 23 gennaio faccio un ordine X dell'articolo Y che costa 10 euro
tra un mese il fornitore che mi vende l'articolo dice che costa di più ed io
sono costretto a venderlo a 12 euro.
vado nel mio bel programmino e modifico il prezzo a 12 euro.
se vado a visualizzare il vecchio ordine fatto il 23 gennaio vedrò:
-se ho utilizzato il metodo 1 il prezzo sarà automaticamente aggiornato ma
non vedrò quanto costava prima
(naturalmente ho parlato di costo ma questo vale per ogni qualsiasi
caratteristicha dell'articolo che si va a modificare)
-se ho utilizzato il metodo 2 il prezzo non sarà aggiornato e quindi se il
cliente vuole lo stesso ordine sono costretto a farne uno nuovo
N.B (nel programma ho una funzione che mi replica un ordine già esistente)
Naturalmente qualcuno potrebbe rispondere che potrei fare dei controlli per
vedere che se caratteristicavecchia <> caratteristicanuova allora posso
gestire la cosa. Ma qui nasce un altro problema: con che criterio decido se
sostituire la caratteristicanuova o tenermi la vecchia, anche nella semplice
visualizzazione di un ordine oppure nella sua stampa di una copia che il
cliente dopo 3 mesi ha perso?
Potrei anche fare una tbOrdiniStorico ma significa che dovrei replicare due
volte gli ordini (due volte più tempo di esecuzione) inoltre rimane sempre
il problema del criterio con il quale decidere se far vedere (stampare,
replicare, usare) i dati vecchi o quelli nuovi.
(Poi c'e' anche il problema della fatturazione che comunque ho risolto
perchè, visto che le ft vengono stampate tramite word, salvo i file di word
in una apposita cartella facendo un riferimento al file in una tabella
inserendo anche gli mporti della fattura. quindi in questo modo anche se il
prezzo di un articolo cambia, la fattura resta sempre la stessa.)
In fin dei conti, voi come vi comportereste (o come vi siete comportati in
situazioni analoghe) e perchè?
Gradirei ricevere se possibile una vostra soluzione al problema
Spero di essere stato chiaro e scusate la lunghezza!!
Grazie a coloro che anche solo leggerano questo post!

 Grazie a coloro che anche solo leggerano questo post!
Scusa tanto, ma è così difficile fare uno storico degli ordini e degli
articoli, limitandolo - tipo -
ad un anno, mettendo un campo data nelle tabelle articolo, ordini, storico
articoli e storico ordini
che indica la data di validità del prezzo( o di ultima validità nel caso
degli storici )?
O ancora più semplice, non ti basta aggiungere un campo "totale ordine"
all'interno della
tabella ordini, così puoi emettere la fattura quando ti pare?
O mi sono perso qualcosa?
Ciao
Andrea

 situazioni analoghe) e perchč?
Una soluzione, la migliore per come la vedo io, e' sempre la solita: date di
validita'
Alla tua tabella base con gli articoli devi aggiungere due colonne (o una o
cinque o una tabella collegata, l'implementazione reale e' un dettaglio) con
l'inizio e la fine di validita' dell'informazione; supponendo, come e' vero
nella maggioranza dei casi, che tu non abbia periodi sovrapposti, la tua
chiave articolo non sara' piu' quindi solamente un identificativo ma la
combinazione tra l'ID e la data di inizio validita'
Tutti gli accessi dovranno essere sempre fatti in funzione di una data
singola che stabilisce il contesto temporale in cui operare: faccio un
ordine ora? cerco l'articolo 5 dove le date di validita' comprendono nella
data di oggi (iniziato prima, scaduto dopo), voglio rivedere un ordine di
tre mesi fa? uso sempre ID=5 ma la data memorizzata a suo tempo
In questo modo puoi ottenere due risultati: limiti la duplicazione dei dati
nella tabella degli ordini (basta comunque l'ID articolo, perche' l'ordine
in se ha gia' una sua data che determina il contesto), e puoi continuare a
ereditare automaticamente le variazioni fatte sulla tabella, laddove la data
non deve cambiare.
L'unica modifica concettuale al tuo programma e' che l'utente deve essere
messo in grado di discriminare se una modifica alla tabella di base e' da
considerarsi come una semplice correzione (ad es. un prezzo sbagliato, che
quindi deve essere ereditato anche dai record collegati gia' esistenti)
oppure una variazione effettiva, nel qual caso deve inserire un nuovo
periodo di validita'.
A basso livello questo si traduce nel primo caso in un semplice UPDATE,
mentre nel secondo diventa un UPDATE del record esistente (perche' ora non
e' piu' da considerarsi "attuale") e un INSERT di una copia dello stesso con
i nuovi parametri e le nuove date.
L'aumento di record in questo modo e' limitato alla sola tabella base, non a
quelle operative, cosa che in genere non aumenta in modo apprezzabile il
carico sul DB.
Non ho esperienza diretta con il tipico gestionale che descrivi ma questo
concetto si applica molto spesso in ambito DB, in molti contesti differenti.
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 Il problema č questo:
(snippato)
Come hai detto tu, probabilmente i pareri sono diversi...
io, nel mio piccolo, ho fatto una distinzione logica tra i parametri che possono
variare nel tempo (ad esempio il costo) e quelli che invece sono logicamente
fissi (nel tuo caso direi che una variazione di un altro parametro modifica di
fatto l'articolo, per cui se devo cambiare il tipo di pelle, per esempio, direi
di introdurre un nuovo articolo, piuttosto che modificare il vecchio). Quindi
quando devo fare un ordine, aggiungo all'ordine l'id dell'articolo e tutte le
informazioni suscettibili di cambiamento. Praticamente una scelta intermedia tra
le due che hai proposto :-)
Salutoni, e tieniti sů (o su?) :-)
Sergio


Io sono un dummies ma ti do il mio modesto parere maturato in una prova di
un gestionale che sto facendo...
1)Ho una tabella con i prodotti in generale(compreso di campo prezzo_finale,
cioè con iva etc...)
2)Ho una tabella con gli ordini effettuati (clinte, numero ordine, data,
totale_ordine)
3)Ho una tabella in cui registro l'uscita dei prodotti (gli ordini o le
vendite, a seconda dei casi decremento il magazzino o meno) e ho un campo
nella tabella che associa la voce del prodotto ad un determinato ordine...
Quando richiamo un ordine lui va a prendere i dati dell'ordine dalla tabella
2) e i dati dei prodotti dalla tabella 3) in cui sono registrati i prodotti
relativi a quell'ordine con tanto di prezzo(calcolato al momento
dell'ordine)...
Fatemi sapere cosa ne pensate, sono alle prime armi e quindi può essere che
sbagli in qualcosa

 caratteristicha dell'articolo che si va a modificare)
mi rende perplesso, se troppi campi della tua tabella articoli sono
importanti , allora buttati sulla 2 usando la tblordini ma tenendo in
considerazione : "Clona Fattura" e "Crea StessaFattura Aggiornata" che il
primo ti piglia i dati di tblordini e il secondo di tblarticoli
Che ne pensi ?

 Sergio
Alex

 [cut]
Esatto, distinguendo i dati fissi ("anagrafica") da quelli fiscali
("artfisca") direi che m piace ^_^
Alex

Anche io ho fatto un prg per la vendita di articoli da calzaturificio per
agenti (distribuito ad una grossa azienda , circa 5.000.000 di articoli
venduti all'anno), e nel dettaglio dell'ordine mi salvo i dati dell'articolo
in quanto questo sono soggetti alla stagionalità e alla linea; quindi
primavera estate 2003
esistono e poi dopo non si sà. Siccome la tabella articoli deve essere
'leggera' non è detto che a distanza di 10 mesi l'articolo sia più presente
, quindi senza referenza in questa tabella , non punti più nulla. Questo
valoe anche per la tabella dettaglio del dettaglio ( taglie di ogni singolo
capo)
Comunque a mio giudizio ognuno deve comportarsi come più gli è congeniale la
strutturazione del programma. Io mi sono adattato alla struttura del
gestionale
, il quale scambia i dati con i vari portatili on line
Saluti
Paolo

 primavera estate 2003
infatti è questo che cercavo di spiegare... per le calzature da una stagione
all'altra cambia tutto

 sbagli in qualcosa
Si ok, ma se fai un ordine oggi e fra tre mesi vuoi ristamparlo e l'articolo
che avevi nell'ordine è cambiato o non c'e' più... come lo risolvi???

 stagione all'altra cambia tutto
mah, io porto le stesse da anni... :-)
Salutoni
Sergio


Penso che a breve mi suiciderò
:-D
Comunque la soluzione potrebbe funzionare ma leggendo i vari post penso che
dovrò usare il metodo 2 + il tuo suggerimento (che non è per la fattura ma
per l'ordine) perchè per le fatture ho risolto in quanto prendo i prezzi etc
dall'ordine...

 le due che hai proposto :-)
Purtroppo, come spiegato piů in basso, per le calzature non esiste nessun
parametro che non puň variare nel tempo.
Anche se č vero che se ho l'articolo X fatto con pelle umana, se metto un
articolo Y fatto con pelle di struzzo questo č un altro articolo
ma i produttori di calzature se vedonoche l'articolo X con pelle umana non
si vende, tengono tutto uguale e mettono solo la pelle di Cammello... ma
sempre articolo X resta....
Quindi č una soluzione che non posso intraprendere

 validita'
Anche questa è una soluzione che potrebbe funzionare ma secondo me crea
troppi problemi all'utente che deve impostare una data di validità delle
informazioni o comunque, se viene impostata in automatico, l'utente potrebbe
sempre cambiare i dati prima della "scadenza"....
c'è da ragionarci un pò su..

 Quindi è una soluzione che non posso intraprendere
Alla faccia dell'organizzazione... per cui, se io ordino al mio fornitore di
calzature, mettiamo in giugno, l'articolo 723, mi arriva una cosa, se rifaccio
lo stesso ordine in ottobre me ne arriva un'altra?
Con dei presupposti così, come pretendono di fare una gestione informatizzata?
Salutoni
Sergio

 O mi sono perso qualcosa?
Probabilmente si...
la questione non è solo quella di avere uno storico degli ordini, degli
articoli etc ma anche quella che l'utente deve poter modificare qualsiasi
caratteristica dell'articolo ma l'ordine deve avere la possibilità di essere
"clonato" in un altro mettendo i nuovi dati o i vecchi.

 Con dei presupposti così, come pretendono di fare una gestione
informatizzata?
Infatti... è molto complicato ma si può!

 ha scritto nel messaggio
news:b0p0l0$qhq1h$1...@ID-173193.news.dfncis.de...

ROTFL!
[Qualcuno mi ucciderà per questa risposta con il solo ROFTL! per questo
aggiungo]
ROTFL!

 un'altra?
Anzi, ripensandoci, potrebbe anche succedere che io ordini 20 paia di calzature
modello 703, e me ne arrivano 4 di pelle e 16 in pitone!
Sempre peggio
Salutoni
Sergio

 ha scritto nel messaggio
news:xGTX9.37512$ZE.10...@twister2.libero.it...

L'utente fa quello che il tuo programma gli consente di fare; se corregge un
dato puoi considerarlo un semplicemente UPDATE, pero' gli dai la
possibilita', sia a livello logico ma anche ben distinta a livello di
interfaccia grafica, of course, di inserire un nuovo prezzo per lo stesso
articolo (anzi nuove caratteristiche in generale, visto il discorso sui
modelli di calzature che fai in un'altro messaggio); a questo punto il
"lavoro sporco" di scadenza di un articolo e creazione dello stesso con
nuova validita' puo farlo la logica del tuo programma.
Al limite l'utente potrebbe anche non aver bisogno di vedere nessun campo
data da nessuna parte... fai in modo che l'elenco degli articoli rispecchi
sempre la situazione attuale degli stessi, e prevedi una funzione a parte
che invece genera un piccolo rapporto sui cambiamenti effettuati sul singolo
elemento, dal primo inserimento a oggi (che ottieni con una banale SELECT
per ID secco)
Semplice ed elegante, IMHO


[cut]
Stiamo parlando di un grossista che acquista scarpe da vari produttori
vero? Diciamo di si :-P
I produttori di scarpe, ma vale anche per maglierie ecc...
hanno un catalogo dei prodotti per la stagione, quindi indicativamente
due volte l'anno aggiornano il catalogo
Se vuoi tenere "tutto aggiornato", anche leggendo le considerazioni
degli altri post, una soluzione potrebbe essere quella di memorizzare i
cataloghi
dei vari fornitori e assegnarli un codice interno univoco
in modo che i clienti del tuo grossista possano usare questo codice per gli
ordini.
La complicazione grossa è il data entry necessario per implementare una cosa
del genere....
Forse ho scritto un mare di ca##te, ma spero di essere stato utile :-)
--
bye BlackMagic
ICQ# 85485468

 la maggioranza!
...
Ho letto velocemente le opinioni di tutti. Ci metto anche la mia:
L'ordine (la riga) deve contenente (e "congelare") tutte le informazioni che
sono state digitate (o accettate in proposta dalle condizioni correnti
dell'articolo) in quel momento. Un istante dopo l'articolo può cambiare
clamorosamente, ma l'ordine deve restare quello che è, anche perchè, magari,
l'hai già spedito al cliente.
Se fra gli accordi ci sta anche una variazione di prezzo "in corso d'opera"
basterà (magari con un comando cumulativo) variare i prezzi (e le altre
cose) sulle righe d'ordine.
Analogamente se cambiano le caratteristiche dell'articolo da parte del
fornitore, si varierà l'articolo (in modo che le nuove condizioni vengano
proposte/replicate per i nuovi ordini clienti) ed eventualmente gli ordini
al fornitore ancora in corso.
In tal modo l'articolo rispecchia sempre la situazione corrente, gli ordini
mantengono invece quanto è stato fatto (ed eventualmente, ma solo
esplicitamente, variato nel tempo) sugli stessi, magari tenedo conto di
condizioni particolari che sono indipendenti dalle variazioni dei costi. Le
ristampe (e lo storico in genere) sono quindi perennemente e fedelmente
garantite.
Ma non ho ben capito, visto che si parla di ordini clienti (ma la stessa
cosa può valere, al contrario, per ordini fornitori), perchè tu debba
toccare i prezzi sugli ordini già confermati dai clienti. Se non c'è una
clausola (capestro) esplicita, io, tuo cliente, se permetti, quando accetto
un ordine, pretendo che anche tu lo rispetti. Poco m'importa se fra la
conferma e la consegna i tuoi fornitori hanno cambiato le condizioni... Non
credi?

 :-D
Ma poi ti tocca cambiare nick...
Bye, G.

 ha scritto nel messaggio
news:b0p752$r8692$1...@ID-108681.news.dfncis.de...

Hai ragione... come sarà???
SotterratoMorto??? No... troppo banale...
potrei fare
MiSonoUcciso... oppure TagliamiLeVene oppure Sparami...
vedremo..


Tutto quello che hai detto è giusto.. e così sto gestendo il programma per
il momento.
Ma il cliente ha voluto fare in modo che se
Il suo cliente oggi fa un ordine di 200 articoli diversi.
Tra 3 mesi ne vuole fare un altro UGUALE.
L'utente clicca sull'ordine, poi su un pulsante e PLOF! l'ordine viene
clonato in uno nuovo.
In questo modo però le info restano quelle di tre mesi prima e se i prezzi o
le caratteristiche sono cambiate ecco che nasce il problema..

 le caratteristiche sono cambiate ecco che nasce il problema..
Non č un grosso problema: Mentre cloni (duplichi) le righe sul nuovo ordine
ne rilevi i dati "freschi" dalla tabella articoli, come se le righe
venissero inserite a mano.

venissero inserite a mano.
Concordo in pieno con quanto dice Lupo.
Anche io gestisco cosě gli ordini ^__^
Ciao
Aran Banjo
<math> 2 + 2 = 5 for sufficiently large values of 2</math>


il problema, come icevi tu è che i fornitori
potrebbero assegnare lo stesso codice
a scarpe di modelli diversi (non proprio modelli
ma caratterirstiche diverse),
quindi come ti hanno già suggerito dovrai tenere
distinti il modello dai suoi attributi (numero, colore ecc...)
anche perchè sull'ordine di X scarpe di modello Y
il compratore avrà necessità di numeri diversi, si spera :-)
e di colori diversi), quindi il prezzo finale della scarpa lo dovresti
gestire con gli altri attributi...
Quando poi decidi di cambiare prezzo, basta che ti memorizzi
la data di cambiamento, all'utente fai credere di modificare un prezzo,
in realtà tu aggiungi un nuovo record con il prezzo cambiato
dalla data X, in questo modo per ogni ordine vecchio puoi risalire
al prezzo al momento dell'ordine stesso (che casino ho fatto)
poi valuta te sul campo :-)



semplice...
1)nella tabella3 io passo un valore prezzo e non una relazione con il prezzo
della tabella1 per cui se anche successivamente questo cambia nella tabella
3 ho sempre il valore al momento dell'ordine...
2)i prodotti non possono essere cancellati dal db(per non intaccare
l'integrità referenziale) ma essere attivati o disattivati, nei vari form
nella stringa sql io pesco solo gli articoli, i clienti , i fornitori attivi
e mai quelli inattivi di cui però conservo i dati....possono sempre tornare
utili, oggi non lo uso + ma domani?
Spero di averti aiutato ma mi interessa sapere il tuo giudizio...grazie

La tentazione č di di una tabella con tutti i dati.
Dopo mesi la tabella si gonfia e tutto rallenta. Sono dolori
Impostando un sistema rigido di costruzione del documento dove vanno
inseriti e stampati i valori dell'ordine , celle di Tabella in Word o celle
di Excel ; successivamente posso leggere i valori presenti nelle celle.
Posso fare un confronto tra i valori delle celle e quelli della tabella , se
diseguali adotto una procedura.
La ho buttata lě.
giuseppeD

 vedremo..
IMHO, hai due possibilità: o dall'aldilà riesci ad accedere
ad Usenet (e mi piacerebbe vedere che IP usi :-) ), o ti
tocca vedere se la nuova reincarnazione è in un essere
umano...
Un Paperino "appropo', come va il Karma ?"

 piacerebbe vedere che IP usi :-))
Dal paradiso non saprei, ma dall'inferno senz'altro: 207.46.249.190
Lokar.che.ha.subito.troppa.influenza.di.Lupo
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org


Ok. funziona se il dato che va a cambiare è solo il prezzo.
Ma io ho diversi dati di un articolo che possono cambiare.. quindi a sto
punto mi conviene copiarli tutti nell'ordine, senza nessuna refernza.

 >venissero inserite a mano.
Infatti... ma mi scoccio di riscrivere intere righe di codice :-(((