Il 04/01/08, Marco Quarona <[EMAIL PROTECTED]> ha scritto:
>
> 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]
>
> Personalmente mi sono trovato molto in vari db dove esisteva una tabella
unica soggetti in cui si trovavano clienti\fornitori etc ed i campi di
questa tabella erano esclusivamente oltre alla distinzione, quelli comuni
(indirizzo, cap etc) Poi si relazionavano le varie tabelle, ad esempio c'era
una tabella con i fatturati che veniva relazionata sia con il soggetto
cliente che il soggetto fornitore, ma non con quello dipendenti.
Molto importante è risultata la tabella contatti collegata sia a clienti che
fornitori, in quanto nell'ambito di un'azienda ci si può voler rivolgere
telefonicamente, via e-mail o altro al responsabile dell'ufficio acquisti a
quello delle vendite, magazzino etc etc ognuno di questi contatti si
relazionava poi con la tabella recapito (che si utilizzava anche per i
soggetti). Qui avevamo record con telefoni e record contenenti e-mail in
quanto ci si trovava con svariati numeri di telefono e mail per soggetto e
anche per contatto.
Una tabella importante era la tabella azienda che poi era relazionata con le
tabelle soggetti e tabelle contabili, tabelle numeratore per permettere una
gestione multiaziendale.
ciao
pac
