Ciao Berserker79,
intanto vorrei precisare che questa è una proposta oltre a tutto è prematura perché, come già detto più volte, non siamo ancora in possesso dei dati basilari per poter creare le relazioni (tabelle).
Prima occorre che voi mandiate tutte le voci che vanno trattate dal nostro database.
Le proposte si fanno per essere discusse, per valutarne i pro e i contro vi chiedo solo di ponderarle in tutti gli aspetti e, come giustamente hai fatto, dare un parere.
Quelli che sanno quali dati occorre avere registrati circa i clienti, i fornitori, i vettori e l'organizzazione siete voi.
Io vi ho mandato a tal scopo dei modelli
ott con possibilità di note proprio perché completaste commentandole le voci già da me estrapolate dai documenti inviati da Tornu.
So benissimo di aver proposto diciamo così un progetto azzardato, uno degli assiomi dei database relazionali è appunto quello di ben separare ogni cosa per poi ricollegarla con correlazioni.
Io comunque ho proposto questo schema abbozzato ed estremizzato (tutto nella
anazie) per far capire il concetto.
Non è che così progettato
anazie sia un guazzabuglio dove finisce tutto mischiato, noi abbiamo
le tabelle dei soggetti ben separate fra loro,
anazie è solo la tabella che le supporta, se decideremo di adottare questo schema dovremo anche decidere quali dati sono in essa superflui e vanno spostati nelle tabelle soggetto.
Se poi in punta di diritto filosofico vogliamo guardare ad anazie sul lato relazionale noi in effetti dovremmo convenire che essa contiene solo ed esclusivamente indirizzi.
Mi stupisce poi che proprio tu dica questo di una tabella che comunque è ben suddivisa in campi mono dato con record solidamente collegati alle tabelle “madri”, non sei tu colui che ha parlato di grandi tabelle suddivise in “mini tabelle” con campi
pluridato che gestiscono tutta l'attività del database professionale su cui lavori?
Comunque sia, ripeto, occorre ben ponderare i pro e i contro, una struttura così concepita per me renderebbe più agevole trattare i dati delle aziende tutte e non dimentichiamoci del personale.
Tenete conto che se separiamo tutto tutto poi comunque dovremmo appoggiarci a delle viste che più o meno lavorerebbero sugli stessi concetti.
...proprio non riesco a concepire una tabella che contiene records che hanno un significato a seconda di quale colonna è valorizzata (idcli, idfor, ecc..)...
Scusa ma che modo è di descrivere le foreign key? Quello li è il metodo più solido e sicuro di legare dati fra due tabelle, non esiste metodo più certo, puoi stare tranquillo al 100% che quanto è scritto il quella tupla è parte integrante dei record della tabella “madre”.
Su NULL mi devo essere spiegato male, sono d'accordo nel cambiarlo con dati più esplicativi che oltre a tutto evitino il grande problema che quando un amministratore di database vede il campo vuoto entra subito in paranoia. Ad esempio se abbiamo il classico campo che prevede il colore dei capelli e uno è calvo mi sta bene si cambi NULL con l'acronimo di “non applicabile”.
Quello che non vorrei è il cambio indiscriminato e mi sono permesso di fare un esempio solo per farmi capire. Il campo NULL è previsto dallo standard SQL e vi sono comandi ad hoc per trattarlo.
Quando il progetto sarà terminato forse non ne sopravviverà nessuno.
