At 09.05 04/01/2008, Filippo Cerulo wrote:
Tornando al discorso Clienti / Fornitori, anche
in questo caso non sono daccordo.
Supponendo di impostare un valore intero,
chiamato ad esempio TIPO con questi valori:
0=Cliente/Fornitore, 1=Solo Cliente, 2=Solo
Fornitore, ogni volta che devo fare una ricerca
sull'archivio dei Fornitori dovrei impostare un
criterio del genere: "TIPO=0 or TIPO=2", che
comporta pur sempre l'esecuzione di una Query.
Quindi a volte duplicare i Dati su due Tabelle
può essere conveniente, ma si giudica caso per caso.
Anche se la discussione è comunque un po' OT, porto la mia esperienza.
Lavoro da più di sei anni ormai su un sistema a
cui ho partecipato sin dalla sua progettazione
più concettuale (mi occupo di sviluppo e
progettazione software). Sin dalle sue basi era
stato pensato per poter essere adeguato a realtà
aziendali differenti e dunque si desiderava una
soluzione che non fosse costruita sul singolo
caso. Replicando alcune scelte fatte con la
versione precedente del sistema, abbiamo creato
una tabella Fornitori, una tabella Clienti e una
tabella Aziende (per i vettori, gli
spedizionieri, e cose del genere). In più c'è una
tabella Sedi che identifica le varie sedi
dell'azienda "proprietaria" del sistema. Per
chiarire (spero), i fornitori sono quelli che
mandano il materiale ad una sede, che lo riceve,
lo lavora e lo spedisce a un cliente. Le aziende
entrano nel processo quando, per esempio, devo
indicare in una spedizione il vettore usato per il trasporto.
Tutto bene, finché non si desidera fare invii di
materiale tra una sede e l'altra. Non è
possibile, perché tutte le fasi del processo
dalla lavorazione alla spedizione necessitano
dell'informazione del cliente. Che fare, cambiare
il sistema in modo tale che ci siano due strade,
una verso clienti e una verso sedi? Alla fine
optiamo per creare i cosiddetti "clienti/sedi",
ovvero la stessa entità assume due facce collegate tra loro.
Dopo un po', però, si vuole anche tener conto che
i clienti possono inviare materiale alle sedi,
oppure tener conto delle giacenze di materiale
presso i fornitori, o ancora spedire materiale ai
fornitori. Per un motivo o per un altro, le varie
esigenze vengono accontentate in modo differente,
inserendo i clienti nell'anagrafica fornitori
senza però legare questi record a quelli dei
clienti, creando "clienti/sede" per i fornitori,
creando una biforcazione nel processo di
spedizione bolle per poter spedire
alternativamente verso fornitori o clienti.
Insomma, un guazzabuglio di soluzioni e di
duplicazione dati. Lascio perdere poi i casini
derivanti dai disallineamenti che si vengono a
creare tra i campi di anagrafica di un fornitore
e di un'azienda (telefoni più lunghi su una
tabella e più corti sull'altra, per esempio).
Ora, se dovessi riprogettare il sistema,
riassumerei le tabelle Fornitori, Sedi, Aziende e
Clienti in una sola: Enti. Un'unico contenitore
per tutti i dati anagrafici e tipici di ogni
soggetto di questo tipo (nominativo, indirizzo,
contatti eccetera). E per i dati tipici di una
particolare entità (ad esempio, il mercato per i
clienti, la gestione dell'ingresso per la sede,
eccetera) delle tabelle figlie con i soli dati
non comuni. In questo modo, ogni volta che devo
far riferimento ad una di queste entità, per
indicare ad esempio il mittente di una bolla in
entrata, oppure il destinatario di una
lavorazione, di un ordine o di una spedizione,
non devo sapere se è un fornitore o un cliente o
chissà cosa: sarà semplicemente un Ente. E
tramite tabelle dedicate, indicherei quali enti
sono fornitori per un ente e quali sono per esso clienti.
Naturalmente, questo è un caso di un sistema
complesso, che deve soddisfare esigenze di
aziende molto diverse tra loro e che anche al
proprio interno hanno gestioni di materiali molto
differenti. In caso di piccole applicazioni,
tutto questo probabilmente non serve. Però volevo
dire la mia, perché sinceramente non credo che il
problema sia aggiungere un filtro in una query
per capire se un dato record è di un cliente o di
un fornitore, visto che i loro dati sono su un
unica tabella. In un sistema elaborato come
quello da me esposto, è davvero il più piccolo
dei problemi. Spesso già la duplicazione del dato
su più tabelle (o anche sulla stessa...) è un problema ben maggiore.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
