In merito a come realizzare le tabelle di un database esistono le forme normali (il livello più basso è 1, il più alto è 6) che stabiliscono delle linee guida da seguire. In linea di massima arrivare alla terza forma normale è lo standard di fatto.
In merito alla vostra discussione riguardo all'organizzazione delle anagrafiche, vorrei farvi riflettere in termini "object oriented" su quale sia la forma più efficienti in termini di spazio. Se definiamo i dati principali di un'anagrafica astratta di sicuro troviamo l'identificativo (es: cognome, nome, codice fiscale per una persona fisica oppure ragione sociale, partita iva, codice fiscale per un'azienda) l'indirizzo (che possiamo suddividere nei campi nazione, stato/regione, provincia, città, via, numero civico, CAP (*)) e via via tutti i dati relativi a numeri di telefono, email, fax, ecc. (*) il cap per le grandi città non è sempre lo stesso, varia in funzione del distretto/quartiere/circoscrizione. Ampliando il ragionamento e pensando alle aziende, probabilmente non solo ci interessano i dati dell'azienda, ma magari di alcuni dipendenti con cui abbiamo a che fare; in questo caso si può creare una tabella Contatti (in relazione con l'azienda) contenente un set di dati ridotto (es. cognome, nome, ufficio ed i soliti contatti tel. email ecc.) che poi potranno essere gestiti con una relazione master/dettaglio. Come si può tener conto di un cliente o di un fornitore o di un azienda che è entrambi o nessuna di queste? Con dei campi flag (un campo contatore non va bene perché un'azienda può essere sia cliente che fornitore) che possono essere dei boolean o dei char o degli int a scelta. In questo modo aggiungere una categoria non sarà mai traumatico (al massimo richiederà una query ALTER sui record). Non è nemmeno tanto complesso consentire che l'anagrafica possa gestire sia persone fisiche sia aziende nella stessa tabella, sempre con l'aiuto di un campo flag, (tabella principale anagrafica + 2 tabelle secondarie una per l'identificativo delle persone fisiche e una per l'identificativo delle aziende); la gestione delle maschere invece è un pochino più complessa. Personalmente non uso base per queste cose, preferisco utilizzare il buon C++ Builder e collegarlo ad un db a scelta dei clienti ed usare degli oggetti che si chiamano frame (una specie di sub-contenitori a livello form) per gestire i campi delle persone fisiche e delle aziende e poi dinamicamente attivarli nella form (in sostanza a turno uno dei 2 è visibile e l'altro invisibile, essendo sovrapposti viene bene). In alternativa vi invito a riflettere in termini di "incapsulamento" e quindi pensare ad una di queste 2 soluzioni: 1. una tabella base da cui "derivare" delle tabelle specializzate (senza preoccuparsi troppo all'inizio di definire tutto per bene, mal che vada 2 o 3 refactoring sistemano tutto) 2. una tabella per ogni "record elementare" (es. indirizzo) linkate tramite relazioni alla tabella principale contenente i dati che diversificano il tipo di dato finale (es. una tabella fornitori che richiama un record indirizzo ecc.) Io preferisco la soluzione con una tabella unica per l'anagrafica con i campi flag, ma anche le ultime 2 non sono male in certe situazioni. Per progettare il db vi consiglio l'uso di DbDesigner 4 che consente l'uso di quasi tutti i db visto che può utilizzare i driver odbc e quindi vi può aiutare sia per il reverse engineering sia per verificare che il db che avete progettato è allineato con quello realizzato, ed oltre tutto è molto RAD come applicativo.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
