Generazione2000 ha scritto: > Micron Engineering ha scritto: >> Filippo Cerulo ha scritto: >> >>> Micron Engineering ha scritto: >>> >>>> ora... a me sembra sia meglio: >>>> >>>> TAnagrafica: >>>> IDAnag, AziendaPersona, IDAziendaPers >>>> >>>> TAnagAziende: >>>> IDAzienda, RagSociale, PIVA >>>> >>>> TAnagPersoneFisiche: >>>> IDPers, Cognome, Nome, CodiceFiscale >>>> >>>> TIndirizzi: >>>> IDIndirizzo, Nazione, Città, CAP, Via, NumeroCivico, Telefono, Fax, >>>> Email, Cellulare,WWW, IDAziendaPers >>>> >>>> TConti: >>>> IDConto, TotOrdinato, TotPagato, TotScaduto, IDAziendaPers >>>> >>>> dove i campi ID sono le foreign key tra le varie tabelle. L'unica >>>> fk che >>>> merita descivere è IDAziendaPers che si relaziona con IDAzienda o >>>> IDPers >>>> in funzione di quali record filtrare. >>>> >>> Potrebbe anche essere meglio, se non fosse che, oltre a progettare la >>> maschera di immissione, ci devi fare un bel lavoro dietro per mettere >>> tutti i dati al posto giusto..... >>> >> per questo esistono le query. Le tabelle non devono essere pensate in >> funzione dei dati da presentare in un report o in una maschera, devono >> essere un sistema efficiente di memorizazione, diciamo il livello più >> basso, il livello intermedio sono le query che forniscono i dati che >> servono per maschere e report. In sostanza una maschera o un report >> dovrebbero ricevere i dati da una query e non direttamente da una >> tabella. E comunque non è un lavoro gravoso e permette l'espandibilità >> del db al cambiare delle esigenze, il tutto in modo molto flessibile. >> Purtroppo tu come molti altri vi concentrate troppo sulla presentazione >> dei dati e non sull'implementazione/gestione. Un pattern molto utile da >> seguire è MVC che razionalizza la struttura dell'applicazione. >> >> >> >> ------------------------------------------------------------------------ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > Ciao, > entro in ritardo nella discussione, io avrei una bozza pronta, > completa di tabelle e, in parte già funzionale, di un gestionale per > negozio. Interamente scritto da me facendo uso di php/Mysql > per quanto concerne le tabelle questo è un mio schema, se può essere > utile... > > ciao > > Stefano > .... Certo è la struttura "standard" di un db per un gestionale e secondo me ha pregi e difetti delle strutture standard. L'esperienza personale che mi ha fatto analizzare diversamente le strutture dati per un db da gestionale è la soluzione del problema del percorso ottimo per le consegne dei furgoncini dei surgelati (o dei pacchi se preferisci). Un grosso limite delle struttre standard, anche se può sembrare strano, è la ricerca di tutti i clienti nella stessa via con numero civico diverso. Per ottimizzare il percorso in una via come può essere la Cristoforo Colombo a Roma è essenziale staccare il numero civico dalla via. Altri problemi apparsi furono la molteplicità dei numeri di telefono, le differenze tra magazzini per la consegna della merce e l'indirizzo per la fatturazione ecc. Inizialmente l'applicazione aveva una struttura simile alla tua, dopo la consegna iniziale il cliente si accorse di cosa gli serviva realmente e cominciò a chiedere modifiche in continuazione; per ovviare alle difficoltà e continue modifiche alla struttrua del db con conseguente recupero di dati optammo per riscrivere la base di dati in modo flessibile ed analizzando rigorosamente i tipi di dati in modo da non duplicarli mai. Il risultato è che l'applicazione è più veloce di quella originale del 60% ed ha una flessibilità massima. > ciao > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
