Re: [utenti] Idee per gestionale
Micron Engineering ha scritto: 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. Ah, ma a te sfugge sempre qualche piccolo particolare. La possibilità di editare i dati di una Maschera basata su una Query non è disponibile sempre. Dipende in effetti dal Front End utilizzato, ed inoltre non è quasi mai possibile (a meno di giri di valzer...) su query uno a molti. Senza contare che l'aggiunta di un Record presuppone, nella tua ipotesi, comunque un lavoro su più Tabelle, passando magari per qualche sana istruzione Sql. Tutto per risparmiare campi? No, perchè strutturare i Db come si è proposto in questa discussione non è certo un modello di semplicità 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. Vabbè, se ti astenessi di fare ipotesi sul metodo di lavoro degli altri senza conoscere i particolari, magari sarebbe meglio. Qui stiamo facendo una discussione puramente teorica, comunque OT, su un'ipotesi di partenza abbastanza banale. Nei casi reali ho vistro strutture di Db di Gestionali anche famosi, tenute insieme col super attack. Ognuno ha il suo metodo, e io li rispetto tutti. Ciao. -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
--- [EMAIL PROTECTED] ha scritto: Non importa la forma in cui scrivi una SELECT, questa viene comunque riprocessata e ottimizzata prima di essere data in pasto al motore del DBMS vero e proprio. Nella realtà, ci sarà senza dubbio qualche minima differenza, ma minima. in SQL io dico COSA voglio ottenere, non COME voglio che il computer lo ottenga, fidandomi di come l'interprete del linguaggio è stato implementato. non è così vero quello che scrivi, soprattutto se hai a che fare con tabelle molto grosse e il db è stato configurato per agire in base alle statistiche raccolte sulle tabelle. L'ordine in cui sono elencate le tabelle nella clausola from può influire sulla strategia d'esecuzione. La strategia d'esecuzione, di solito, è modificabile nelle query tramite gli hint. Ciao Davide Dizionari: http://linguistico.sourceforge.net/wiki Esci dall'illegalità: utilizza OpenOffice.org: http://linguistico.sourceforge.net/wiki/doku.php?id=UsaOOo GNU/Linux User: 302090: http://counter.li.org -- Non autorizzo la memorizzazione del mio indirizzo su outlook ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
--- Micron Engineering ha scritto: per questo esistono le query. Le tabelle non devono essere pensate in funzione dei dati da presentare in un report o in una maschera, questo non è poi così vero. Le tabelle o meglio la struttura del db è meglio che sia pensata per ottimizzare i tipi di interrogazione che andranno effettuati su di essa. Se operi con moli di dati elevate (milioni di record) questo tipo di strutturazione del db può essere fondamentale. Ciao Davide Dizionari: http://linguistico.sourceforge.net/wiki Esci dall'illegalità: utilizza OpenOffice.org: http://linguistico.sourceforge.net/wiki/doku.php?id=UsaOOo GNU/Linux User: 302090: http://counter.li.org -- Non autorizzo la memorizzazione del mio indirizzo su outlook ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
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]
Re: [utenti] Idee per gestionale
Generazione2000 ha scritto: Micron Engineering ha scritto: [EMAIL PROTECTED] ha scritto: Micron Engineering wrote: 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. questo DbDesigner 4 può esser collegato a OOo? Mi spiego, uno potrebbe gestire il DB, le query, le mascher ecc con DbDesigner 4 e sfruttare OOo per le stampe ed altre cose grazie al foglio di calcolo. Si avrebbe una soluzione ibrida. bye E'utile per disegnare le tabelle, impostare le relazioni e scrivere le query. Una volta finito il progetto ti crea lo script per la creazione del database completo. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Ricapil Capelli: Stop alla caduta, Via alla ricrescita, Garantito! * * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7110d=4-1 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.13/1207 - Release Date: 02/01/2008 11.29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] ha scritto: questo DbDesigner 4 può esser collegato a OOo? Mi spiego, uno potrebbe gestire il DB, le query, le mascher ecc con DbDesigner 4 e sfruttare OOo per le stampe ed altre cose grazie al foglio di calcolo. Si avrebbe una soluzione ibrida. bye - Per questo allora abbiamo il gestionale bello ceh fatto e fompletamente funzionante. Un progetto Open Source con licenza GPL. Scaricabile previa registrazione gratuita al sito del Team Mosaico (http://www.teammosaico.biz). L'esportazione delle tabelle è semplice e quindi relazionabile ad OOo per eseguire magari i grafici o altra robina varia Lo conosco è stato sviluppato in Delphi, personalmente non lo trovo molto efficiente e la struttura del db è troppo rigida, se hai bisogno di qualcosa in più non puoi aggiungere tabelle ma necessariamente modificare anche quelle esistenti. 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]
Re: [utenti] Idee per gestionale
Micron Engineering ha scritto: Insisto è solo questione di codice... Tutto è questione di codice. Il problema è quando bisogna scriverlo Ciao. Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Micron Engineering ha scritto: Mica tanto vero... in termini di inserimenti e cancellazioni siamo nell'ordine di O(1) e quindi non dipende dal numero di record, per cui in generale bisognerebbe tendere a migliorare i tempi di ricerca (query) che risentono si del numero di record ma risentono ancor di più se per eseguire una query bisogna fare un join su più tabelle. Poi bisogna considerare se l'applicazione è da gestire sul client o sul server o tutta sullo stesso PC. E chi parla di fare Join su più Tabelle? Se cerco un Cliente lo cerco nella Tabella Clienti. Dovrei cercare un'Anagrafica generica senza sapere dove cercare, ma mi sembra un'ipotesi remota. Piuttosto, come sai, i tempi della Query si allungano se aggiungo criteri di selezione, come avverrebbe con una Flag di tipo. Ciao -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo wrote: Micron Engineering ha scritto: Piuttosto, come sai, i tempi della Query si allungano se aggiungo criteri di selezione, come avverrebbe con una Flag di tipo. per dare un taglio meramente pragmatico e non ideologico mi sorge la domanda: ma di quanto si allungano i tempi se si aggiungono dei criteri di selezione? In altre parole, l'aggiunta di criteri di selezione è un motivo di criticità del DB? bye -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Realizza i tuoi sogni con i finanziamenti Finatel! Fino a 50.000 Euro senza spese in pochissimo tempo. Richiedi Informazioni * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7371d=4-1
Re: [utenti] Idee per gestionale
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]
Re: [utenti] Idee per gestionale
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
Re: [utenti] Idee per gestionale
At 12.43 04/01/2008, Filippo Cerulo wrote: Questa è davvero una tesi interessante.. Guarda che è decisamente normale... Cioè tu sostieni che una query del tipo (tradotta in vulgaris): seleziona le Anagarfiche con CITTA='VERONA' dalla Tabella Anagrafiche abbia la stessa velocità di esecuzione di : seleziona le Anagrafiche con CITTA='VERONA' e (TIPO=0 oppure TIPO=1) dalla Tabella Anagrafiche. Prima di tutto dipende se i campi di filtro sono indicizzati o meno. Mettiamo che in questo caso i campi siano indicizzati in modo favorevole alla tua tesi. Ovvero è indicizzato il campo CITTA e non il campo TIPO. A questo punto bisogna valutare la granularità dell'indice e la lunghezza del record. Se su 100.000 record ho 10 record con CITTA = 'VERONA' e TIPO in (0,1), forse la seconda query ci metterà qualche millesimo di secondo in più, perchè oltre a pescare i record dall'indice, dovrà fare un ulteriore esame sui risultati per verificare che i record restituiti rispondano già all'altro criterio di filtro. Ma nel caso ci siano 100 record con CITTA = 'VERONA' di cui uno solo con TIPO in (0,1), la seconda query sarà più veloce perché il tempo di lettura e trasferimento dati di 100 record (al posto di 1) renderanno più pesante la prima. A meno che il tuo scopo sia trovare solo il primo record di un subset di record, ma raramente questo è quello che si vuole, anche perché altrimenti per assurdo la query più veloce di tutte è SELECT * FROM TABELLA. Nel caso in cui invece vi sia un indice con entrambi i campi (CITTA e TIPO) non ci sono santi che tengano: la seconda è ovviamente più veloce. Poi possono esserci da fare sempre considerazioni sulla granularità, ma di certo la prima non potrà _mai_ essere più veloce della seconda. Ovvio che su cento schede neppure mi pongo il problema. Ma su 100.000? Ovviamente, più ci sono record e più le differenze di tempo aumentano. E quanto ti ho appena descritto si mostrerà in modo più netto. Quanto sto dicendo, non lo affermo solo in base alla logica di come funziona un db, ma anche in base all'esperienza che ho maturato... e le tabelle del sistema di cui dicevo che hanno 100.000 record non sono quelle grandi. Quelle grandi hanno 50 milioni di record. Poi, io uso Oracle che è un database abbastanza serio, ma credo che anche Access sappia valutare correttamente le query di cui sopra, usando gli indici che ha, prima di fare scansioni su tutta la tabella. E sulle query complesse come la mettiamo? Meglio relazionare una Tabella Clienti, magari con un indice univoco intero, oppure una select con un paio di parametri ed un OR? Bah, credo che capirai anche tu che non ha molto senso confrontare una query fatta sulla primary key con una fatta su un set di campi non indicizzati... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Marco Quarona ha scritto: At 09.32 04/01/2008, you wrote: In altre parole, l'aggiunta di criteri di selezione è un motivo di criticità del DB? No, a meno che il motore del db (o la il db stesso) siano stati progettati male. I filtri velocizzano le query, non le rallentano. Questa è davvero una tesi interessante.. Cioè tu sostieni che una query del tipo (tradotta in vulgaris): seleziona le Anagarfiche con CITTA='VERONA' dalla Tabella Anagrafiche abbia la stessa velocità di esecuzione di : seleziona le Anagrafiche con CITTA='VERONA' e (TIPO=0 oppure TIPO=1) dalla Tabella Anagrafiche. Ovvio che su cento schede neppure mi pongo il problema. Ma su 100.000? E sulle query complesse come la mettiamo? Meglio relazionare una Tabella Clienti, magari con un indice univoco intero, oppure una select con un paio di parametri ed un OR? E' evidente che se un'applicazione complessa come quella che hai descritto nell'altra mail ha delle necessità particolari, il Db va progettato con cura. Ma il non voler duplicare i campi non deve far dimenticare tutto il resto. Ciao -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
2008/1/4, Filippo Cerulo [EMAIL PROTECTED]: Marco Quarona ha scritto: At 09.32 04/01/2008, you wrote: In altre parole, l'aggiunta di criteri di selezione è un motivo di criticità del DB? No, a meno che il motore del db (o la il db stesso) siano stati progettati male. I filtri velocizzano le query, non le rallentano. Questa è davvero una tesi interessante.. Cioè tu sostieni che una query del tipo (tradotta in vulgaris): seleziona le Anagarfiche con CITTA='VERONA' dalla Tabella Anagrafiche abbia la stessa velocità di esecuzione di : seleziona le Anagrafiche con CITTA='VERONA' e (TIPO=0 oppure TIPO=1) dalla Tabella Anagrafiche. Ovvio che su cento schede neppure mi pongo il problema. Ma su 100.000? E sulle query complesse come la mettiamo? Meglio relazionare una Tabella Clienti, magari con un indice univoco intero, oppure una select con un paio di parametri ed un OR? E' evidente che se un'applicazione complessa come quella che hai descritto nell'altra mail ha delle necessità particolari, il Db va progettato con cura. Ma il non voler duplicare i campi non deve far dimenticare tutto il resto. La velocità non sarà la stessa, ma stiamo parlando di differenze solitamente neppure percepibili. Ciao -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
[EMAIL PROTECTED] ha scritto: Micron Engineering wrote: 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. l'idea originaria era di fare un mini gestionale (funzionale) in OOo. Forse stiamo andando OT, anche per colpa mia. A me queste discussioni fanno anche piacere perchè son comunque fonte di novità, di apprendimento. Non mi pare tu sia OT, certo quando si parla di db si scade su argomenti legati ai db in generale e non su caratteristiche specifiche di base ma questo è inevitabile. E nel momento in cui si parla di organizzare i dati in tabelle... anche questo prescinde da base ma tant'è... và risolto. Paolo -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Un prestito supertasso zero spese? Oggi con Finatel è realtà. Puoi ottenere fino a 50.000 EUR anche in 24 ore. Scopri Come * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7370d=4-1 - No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.13/1207 - Release Date: 02/01/2008 11.29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo ha scritto: Picchiottino Roberto ha scritto: Io, nel mio db per l'azienda, ho una sola tabella con clienti e fornitori, quando faccio una fattura registro id_destinatario e id_mittente, in questo modo riesco a fare la contabilita' di piu' aziende senza problemi. (non che lo usi... ma l'ho utilizzato ...) Mi trovo bene e trovo comodo che dati omogenei siano nella stessa tabella. Quello che oggi e' un cliente domani e' un fornitore e quindi una tabella e' comoda. Vabbè, qui siamo decisamente OT. Tanto per precisare, non stiamo parlando di Clienti e Fornitori, dove, se un'anagrafica è contemporaneamente Cliente e Fornitore, posso anche capire. Stiamo parlando di Clienti e Colleghi (cioè collaboratori al progetto) che non hanno NULLA in comune dal punto di vista di strutturazione del Db, meno ALCUNI campi. Ok facciamo un esempio riduttivo: TClienti: RagSociale, PIVA, Nazione, Città, CAP, Via, NumeroCivico, Telefono, Fax, Email, WWW, TotOrdinato, TotPagato, TotScaduto TFornitori: RagSociale, PIVA, Nazione, Città, CAP, Via, NumeroCivico, Telefono, Fax, Email, WWW, TotOrdinato, TotPagato, TotScaduto TColleghi: Cognome, Nome, CodiceFiscale, Nazione, Città, CAP, Via, NumeroCivico, Telefono, Fax, Email, WWW, Cellulare TContatti: Cognome, Nome, Telefono, Fax, Email, Cellulare, RagSociale, 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. 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. Ciao - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
[EMAIL PROTECTED] ha scritto: secondo te non basta aggiungere un qualche cosa che distingua i clienti dai colleghi piuttosto che i fornitori o i prestatori d'opera ecc? Usando una sola tabella e distinguendo i vari soggetti si evita di avere due distinti archivi per i soggetti. fornitori e clienti in una stessa tabella? per le cose che li accomunano può andare, ma poi andrebbero fatte due tabelle collegate per i dettagli che per fornitori e clienti possono essere molti e molto diversi. E non dimenticate che un cliente potrebbe essere anche fornitore al tempo stesso. Clienti e fornitori possono avere un numero illimitato di telefoni, indirizzi email, domicili o indirizzi di magazzini per consegna e ritiro, conti correnti e metodi di pagamento etc etc Ma sicuramente se non ti pare una buona idea un qualche motivo serio che a me sfugge ce l'hai. avere una unica tabella di partenza in cui inserire alcuni dati di clienti, fornitori, dipendenti ha sicuramente molti vantaggi, ma anche piu' difficile da analizzare e implementare. tabelle separate semplifica molto, ma comporta ridondanza nei dati e ricerche piu' complesse (per cercare per esempio un numero di telefono, devo cercarlo 3 volte in tre tabelle diverse).(ovviamente questo del telefono era solo un esempio: i telefoni vanno in una tabella a parte) Mi guardo un pò lo schema e scrivo due righe. Potrebbe venirne fuori qualcosa di usabile. Credo che il problema più serio siano le stampe, ma può darsi che col nuovo generatore di report di Sun qualcosa si può fare. speriamo in pro-mamma sun Ciao. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: In REGALO 'All the Good Thing' di NELLY FURTADO Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6616d=3-1 -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Un look da modella in pochi secondi, consigliato da Hunter Tylo * * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7111d=4-1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo ha scritto: Questo potrebbe andare bene, ma magari in una prima fase non è strettamente necessario. è proprio nella prima fase che devi prevedere piu' casi possibili, perché poi è un casino ristrutturare tutto il database. Per esempio, prevedi una tabella clienti con un solo campo per il telefono: se hanno due telefoni? tre? dieci? vuoi memorizzare anche tipo di telefono e gestore? Se non decidi di prevedere una molteplicita' uno a molti, per i telefoni e vai avanti con il progetto, quando sorge la necessità è un bel casino. Se prevedi subito due tabelle collegate, poi hai una flessibilità unica. Mi guardo un pò lo schema e scrivo due righe. Potrebbe venirne fuori qualcosa di usabile. Credo che il problema più serio siano le stampe, ma è anche l'ultimo dei problemi da risolvere -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vuoi avere un sito che incrementi il tuo business e porti nuovi clienti? * Icecube.it ha tutte le strategie per la miglior visibilita' rispetto a quella dei tuoi concorrenti Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7352d=4-1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
--- Micron Engineering ha scritto: Ok facciamo un esempio riduttivo: [...] premetto che non ho seguito molto bene la discussione: alcune mail non le ho lette o le ho lette molto velocemente. Volevo solo dire che secondo me: 1) in teoria prima di realizzare un database le domanda da farsi sono altre. Questa è una parte molto teorica che spesso o quasi sempre non viene presa in considerazione, ma che in realtà dovrebbe. Non è presa in considerazione perché è, molto spesso, difficile, se non quasi impossibile, riuscire a realizzarla concretamente e proficuamente. Inoltre i tempi per effettuare questa analisi di solito non ci sono mai ... Alcune tra le domande principali da porsi all'inizio sono: * quanti dati si dovrà gestire (ordine di grandezza) * come la base dati dovrà essere interrogata (capire da subito quali sono/saranno le esigenze degli utilizzatori) * come la base dati sarà utilizzata (ad esempio quanti saranno gli utenti contemporanei massimi?) * quali sono i tempi di risposta attesi per le varie interrogazioni/operazioni da svolgere * se e come può cambiare la struttura/le relazioni/la logica/... nel tempo * ci sono vincoli, limitazioni, ... * cosa potrebbe andare male, cosa potrebbe non essere stato ancora considerato * ... Questa analisi permette di stabilire anche la complessità della struttura del database che si deve creare; permette di capire come deve essere impostata, ... Naturalmente conta molto l'esperienza accumulata nel tempo. Le risposte devono arrivare dopo o mentre si capisce a fondo l'argomento che si deve realizzare. È utile cercare di capire ogni particolare. 2) evitare la duplicazione dell'informazione dove non necessaria per ottenere quanto rilevato al punto 1 3) cercare di ottenere una struttura semplice con il minimo numero di tabelle necessarie, mettere le mele tutte in una stessa tabella, le arance tutte in un'altra, ... sempre senza contraddire i punti precedenti 4) realizzare una base dati che offra la garanzia della consistenza creando tutte le chiavi primarie, gli indici univoci, le foreign key, ... necessarie e indispensabili per tale scopo 5) utilizzare indici e altri strumenti per ottimizzare i tempi di risposta come richiesto dalle specifiche del punto 1 6) realizzare viste per tutto ciò che non è necessario sia una tabella, ma che può è meglio sia visto come tabella da più interrogazioni (se si deve fare una modifica, allora la si fa solo in quella vista) 7) cercare di adottare dei criteri che permettano di identificare e categorizzare ogni elemento del database in modo univoco e veloce 8) ... Ciao Davide Dizionari: http://linguistico.sourceforge.net/wiki Esci dall'illegalità: utilizza OpenOffice.org: http://linguistico.sourceforge.net/wiki/doku.php?id=UsaOOo GNU/Linux User: 302090: http://counter.li.org -- Non autorizzo la memorizzazione del mio indirizzo su outlook ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo ha scritto: Marco Quarona ha scritto: At 09.32 04/01/2008, you wrote: In altre parole, l'aggiunta di criteri di selezione è un motivo di criticità del DB? No, a meno che il motore del db (o la il db stesso) siano stati progettati male. I filtri velocizzano le query, non le rallentano. Questa è davvero una tesi interessante.. in un dbms semplice e leggero probabilmente no, ma in DBMS ideale sì (oracle ci prova). Non importa la forma in cui scrivi una SELECT, questa viene comunque riprocessata e ottimizzata prima di essere data in pasto al motore del DBMS vero e proprio. Nella realtà, ci sarà senza dubbio qualche minima differenza, ma minima. Insomma, comandi equivalenti, per quanto diversi, se il preprocessore funzionasse alla perfezione dovrebbero essere tradotti allo stesso modo. Cioè tu sostieni che una query del tipo (tradotta in vulgaris): seleziona le Anagarfiche con CITTA='VERONA' dalla Tabella Anagrafiche abbia la stessa velocità di esecuzione di : seleziona le Anagrafiche con CITTA='VERONA' e (TIPO=0 oppure TIPO=1) dalla Tabella Anagrafiche. Ovvio che su cento schede neppure mi pongo il problema. Ma su 100.000? queste non sono due select equivalenti (che danno quindi il medesimo output) e quindi non necessariamente hanno la stessa velocità di esec. Cmq in questo caso, anche su 1'000'000 di record, non ti accorgi della differenza. Suppongo che su CITTA sia stato creato un indice (mentre su TIPO no). Facciamo finta che ci siano 1'000 schede di 'VERONA' (0,1%): la select richiede solo di scorrere un elenco di mille schede e dare il risultato. Nel secondo caso le schede che vengono lette sono ugualmente 1000, solo che alcune non vengono stampate (quelle di TIPO=2). SI', ci mettono lo stesso tempo. caso particolare: se si tratta di un'azienda di VERONA e il 99% delle schede contiene quella parola, non abbiamo alcun vantaggio nell'uso di quell'indice. Magari esistono 10 valori equamente distribuiti per il campo TIPO e allora è stato creato un indice su tale campo. In tal caso la seconda select potrebbe essere circa 5 volte piu' veloce, dovendo scartabellare solo tra 200'000 schede (in media). se non esistono indici, allora ci mettono lo stesso tempo (vanno analizzate tutte le schede). INFINE seleziona le Anagrafiche con CITTA='VERONA' e (TIPO=0 oppure TIPO=1) dalla Tabella Anagrafiche. e seleziona le Anagrafiche con (TIPO=0 oppure TIPO=1) e CITTA='VERONA' dalla Tabella Anagrafiche. su un DBMS che non perde tempo ad analizzare prima il comando, queste select potrebbero avere tempi di esecuzione molto diversi, ma su un DBMS con preprocessore queste sono equivalenti. in SQL io dico COSA voglio ottenere, non COME voglio che il computer lo ottenga, fidandomi di come l'interprete del linguaggio è stato implementato. Con i linguaggi procedurali io indico COME e quindi le prestazioni variano enormemente in base a cio' che scrivo. e poi, le prestazioni non sono tutto. la manutenibilità e la possibilità di adattare il lavoro alle nuove esigenze, le vedo molto piu' importanti E sulle query complesse come la mettiamo? Meglio relazionare una Tabella Clienti, magari con un indice univoco intero, oppure una select con un paio di parametri ed un OR? non ho capito la domanda. ciao, Giacomo -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Un prestito supertasso zero spese? Oggi con Finatel è realtà. Puoi ottenere fino a 50.000 anche in 24 ore. Scopri Come * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7370d=4-1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Marco Quarona ha scritto: Nel caso in cui invece vi sia un indice con entrambi i campi (CITTA e TIPO) non ci sono santi che tengano: la seconda è ovviamente più veloce. Poi possono esserci da fare sempre considerazioni sulla granularità, ma di certo la prima non potrà _mai_ essere più veloce della seconda. Caro Marco, ti scordi una piccola cosa. Le Tabelle delle due query NON HANNO lo stesso set di Record: la prima contiene SOLO I CLIENTI, la seconda TUTTE LE ANAGRAFICHE, quindi la prima sarà SEMPRE più veloce della seconda perchè il campo TIPO semplicemente non esiste. Senza questa piccola osservazione, possiamo scrivere quello che vogliamo ed è sempre tutto giusto. Ovviamente, più ci sono record e più le differenze di tempo aumentano. E quanto ti ho appena descritto si mostrerà in modo più netto. Quanto sto dicendo, non lo affermo solo in base alla logica di come funziona un db, ma anche in base all'esperienza che ho maturato... e le tabelle del sistema di cui dicevo che hanno 100.000 record non sono quelle grandi. Quelle grandi hanno 50 milioni di record. Non ho idea su che sistemi lavori, 50 milioni di Record per una Tabella mi sembrano comunque tanti da gestire in ambito PC. Se parliamo di Mainframe, allora tutto cambia. Poi, io uso Oracle che è un database abbastanza serio, ma credo che anche Access sappia valutare correttamente le query di cui sopra, usando gli indici che ha, prima di fare scansioni su tutta la tabella. Come sai, ogni Db ha il suo metodo di ottimizzazione delle Query, quindi non è detto che la strategia migliore sia sempre e comunque la stessa, soprattutto in caso di ricerce complesse. Oracle è un ottimo prodotto, ma non è proprio alla portata di un utente medio di PC. Access funziona bene, è abbastanza veloce ma non è paragonabile ad un server di Db. Il povero Base con HSQL si siede già con 500 schede, figurati. Ciao -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Marco Quarona ha scritto: per assurdo la query più veloce di tutte è SELECT * FROM TABELLA. se la tabella è vuota sì, altrimenti, se ha molti record (50 milioni?) ci mette un sacco una molto piu' veloce potrebbe essere quella che cerca (nella stessa tabella) un valore che non esiste su un campo indicizzato Nel caso in cui invece vi sia un indice con entrambi i campi (CITTA e TIPO) non ci sono santi che tengano: e i Cristi tengono? Giacomo -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Realizza i tuoi sogni con i finanziamenti Finatel! Fino a 50.000 Euro senza spese in pochissimo tempo. Richiedi Informazioni * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7371d=4-1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
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. -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
[EMAIL PROTECTED] ha scritto: Filippo Cerulo ha scritto: Mi guardo un pò lo schema e scrivo due righe. Potrebbe venirne fuori qualcosa di usabile. Credo che il problema più serio siano le stampe, ma è anche l'ultimo dei problemi da risolvere Per me è il primo. Una applicazione senza possibilità concreta di stampare i dati mi pare proprio inutile. Ciao -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
[EMAIL PROTECTED] ha scritto: ... tabelle separate semplifica molto, ma comporta ridondanza nei dati e ricerche piu' complesse (per cercare per esempio un numero di telefono, Io ho scelto tabelle uniche anche per registrare le fatture attive e passve allo stesso modo, inoltre puoi gestire n contabilità dove se un fornitore (che usa il software) fa la fattura a te tu l'hai gia' caricata in contabilità. Ciao Picchio -- Picchiottino Roberto - Monte Bianco TLC - Courmayeur #160087 - http://counter.li.org/ Jabber: [EMAIL PROTECTED] - icq: 239063259 http://www.gnu.org/philosophy/no-word-attachments.it.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo ha scritto: [EMAIL PROTECTED] ha scritto: Filippo Cerulo ha scritto: Mi guardo un pò lo schema e scrivo due righe. Potrebbe venirne fuori qualcosa di usabile. Credo che il problema più serio siano le stampe, ma è anche l'ultimo dei problemi da risolvere Per me è il primo. Una applicazione senza possibilità concreta di stampare i dati mi pare proprio inutile. ovviamente E' lo scopo principale, ma è l'ultimo problema IN ORDINE DI TEMPO su cui focalizzare l'attenzione. Non puoi progettare un report se non sai su quali query si basa. Non esistono le query se non hai pianificato di quali tabelle c'e' bisogno. Se progetti male e devi ristrutturare le basi, rischi di spendere tempo a rifar funzionare anche i report. (personalmente non conosco ancora come si fanno i report in OOo... spero di arrivare presto al capitolo 13 e fare qualche prova) senza il tetto una casa non serve praticamente a niente, ma prima devono essere gettate solide fondamenta (tabelle) e colonne portanti (query e viste) poi il tetto (report) e la facciata imbiancata con fiori alle finestre (grafica inutile nei form). Ciao :-) -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Finatel ti offre il prestito agevolato fino a 50.000 Euro anche in 24 ore. Zero Spese! Scoprilo Subito * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7368d=4-1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
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]
Re: [utenti] Idee per gestionale
[EMAIL PROTECTED] ha scritto: Micron Engineering wrote: 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. questo DbDesigner 4 può esser collegato a OOo? Mi spiego, uno potrebbe gestire il DB, le query, le mascher ecc con DbDesigner 4 e sfruttare OOo per le stampe ed altre cose grazie al foglio di calcolo. Si avrebbe una soluzione ibrida. bye E'utile per disegnare le tabelle, impostare le relazioni e scrivere le query. Una volta finito il progetto ti crea lo script per la creazione del database completo. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Ricapil Capelli: Stop alla caduta, Via alla ricrescita, Garantito! * * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7110d=4-1 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.13/1207 - Release Date: 02/01/2008 11.29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo ha scritto: 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. Ora supponiamo di avere un db impostato come ho proposto e supponiamo che sia disponibile a chiunque. Se a Tizio il db va bene al 90% ma gli mancano dei campi oppure delle tabelle, deve solo aggiungere delle FK per linkare i suoi dati (nuovi) a ciò che già esiste, aggiungere o modificare delle query ed il gioco è fatto. Ho letto anche della mancanza di un contatto skype ecc, ovviamente il mio è un esempio (ridotto) fatto in 5 minuti ma che può essere espanso nel modo consueto: TComunicazioniContatto IDComCon, IDTipoCom, Contatto(*), AziendaPers, IDAziendaPers (*) è una stringa perché potrebbe contenere un numero o una stringa TipoComunicazione IDTipoCom, Descrizione qui basta aggiungere un record per ogni tipo ad esempio num. tel., cellulare, email, skype ecc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
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 # phpMyAdmin SQL Dump # version 2.5.3 # http://www.phpmyadmin.net # # Host: localhost # Generato il: 04 Ago, 2007 at 11:36 AM # Versione MySQL: 4.0.15 # Versione PHP: 4.3.3 # # Database : `fatture` # # # # Struttura della tabella `barcode` # DROP TABLE IF EXISTS `barcode`; CREATE TABLE `barcode` ( `ID` int(12) NOT NULL auto_increment, `BARCODE` varchar(20) default NULL, `IDPRODOTTO` int(12) default NULL, `DESCRPRODOTTO` varchar(80) default NULL, `IDFORNITORE` int(12) default NULL, `FORNITORE` varchar(250) default NULL, `DATA` datetime default NULL, `ATTIVO` int(11) default '0', PRIMARY KEY (`ID`) ) TYPE=MyISAM AUTO_INCREMENT=115 ; # # # Struttura della tabella `carrelli` # DROP TABLE IF EXISTS `carrelli`; CREATE TABLE `carrelli` ( `NUMCAR` int(15) NOT NULL auto_increment, `ANNOCAR` year(4) NOT NULL default '', `DATACAR` timestamp(14) NOT NULL, `PZTOT` int(10) NOT NULL default '0', `PRZTOT` double(10,2) NOT NULL default '0.00', `NOMECLIENTE` varchar(250) NOT NULL default '', `IDCLIENTE` varchar(20) NOT NULL default '', `STATOCAR` char(1) NOT NULL default '', `FATTURA` varchar(10) default NULL, `ANNOFATT` year(4) default NULL, `IDFATTURA` int(20) NOT NULL default '0', `FATTURADDT` varchar(10) default NULL, `ANNOFATTURADDT` year(4) default NULL, `IDFATTURADDT` int(20) NOT NULL default '0', `DDT` varchar(10) default NULL, `ANNODDT` year(4) default NULL, `IDDDT` int(20) NOT NULL default '0', `ULT_MOD` timestamp(14) NOT NULL, KEY `NUMCAR` (`NUMCAR`) ) TYPE=MyISAM AUTO_INCREMENT=51 ; # # # Struttura della tabella `carrellodettagli` # DROP TABLE IF EXISTS `carrellodettagli`; CREATE TABLE `carrellodettagli` ( `NUMCAR` varchar(15) NOT NULL default '', `ANNOCAR` year(4) default NULL, `DATACAR` timestamp(14) NOT NULL, `STATO` char(1) NOT NULL default '', `IDCLIENTE` varchar(15) NOT NULL default '', `ARTCOD` varchar(20) NOT NULL default '', `ARTDES` varchar(250) NOT NULL default '', `UM` varchar(10) NOT NULL default '', `QTA` int(15) NOT NULL default '0', `PREZZOX1` double(10,2) NOT NULL default '0.00' ) TYPE=MyISAM; # # # Struttura della tabella `categorie` # DROP TABLE IF EXISTS `categorie`; CREATE TABLE `categorie` ( `ID` int(10) NOT NULL auto_increment, `nomevisualizzato` varchar(150) default NULL, `categoria` varchar(50) default NULL, `categoriaweb` varchar(50) default NULL, `icona` varchar(50) default NULL, `data_inserimento` datetime default NULL, `data_modifica` datetime default NULL, PRIMARY KEY (`ID`) ) TYPE=MyISAM AUTO_INCREMENT=13 ; #
Re: [utenti] Idee per gestionale
Micron Engineering ha scritto: [EMAIL PROTECTED] ha scritto: Micron Engineering wrote: 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. questo DbDesigner 4 può esser collegato a OOo? Mi spiego, uno potrebbe gestire il DB, le query, le mascher ecc con DbDesigner 4 e sfruttare OOo per le stampe ed altre cose grazie al foglio di calcolo. Si avrebbe una soluzione ibrida. bye E'utile per disegnare le tabelle, impostare le relazioni e scrivere le query. Una volta finito il progetto ti crea lo script per la creazione del database completo. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Ricapil Capelli: Stop alla caduta, Via alla ricrescita, Garantito! * * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7110d=4-1 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.13/1207 - Release Date: 02/01/2008 11.29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] ha scritto: questo DbDesigner 4 può esser collegato a OOo? Mi spiego, uno potrebbe gestire il DB, le query, le mascher ecc con DbDesigner 4 e sfruttare OOo per le stampe ed altre cose grazie al foglio di calcolo. Si avrebbe una soluzione ibrida. bye - Per questo allora abbiamo il gestionale bello ceh fatto e fompletamente funzionante. Un progetto Open Source con licenza GPL. Scaricabile previa registrazione gratuita al sito del Team Mosaico (http://www.teammosaico.biz). L'esportazione delle tabelle è semplice e quindi relazionabile ad OOo per eseguire magari i grafici o altra robina varia ciao Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
2008/1/3, [EMAIL PROTECTED] [EMAIL PROTECTED]: Alessandro Cattelan wrote: Per dare un seguito a quanto proposto in una precedente discussione, ho caricato alla seguente pagina uno schema dei campi e delle tabelle che dovrebbe contenere il database a cui pensavo: http://www.alessandrocattelan.it/XYZ/db.pdf (è un file pesantuccio e forse un po' confuso, ma al momento non sono riuscito a fare di meglio) Posso cominciare a fare delle osservazioni? 1) perchè hai creato due distinte tabelle per client e users? Non è + semplice usare un'unica tabella per tutti i soggetti e distinguerli poi con un campo bool o tinyint in client users collegues ecc? 2) per ogni soggetto c'è la possibilità di indicare un solo indirizzo/recapito. Non è meglio svincolare la tabella degli indirizzi/recapiti da quella dei soggetti in modo che ad un singolo soggetto si possano aggiungere tutti i recapiti che si vuole (uno per Milano, uno per New York ecc)? Ho una risposta semplice semplice: perché non ho molta esperienza con i database e quindi non mi era venuto in mente! :) Comunque a pensarci credo tu abbia perfettamente ragione. Grazie per i commenti! Ale. Vabbe', forse voglio troppo, ma credo sarebbe molto utile e suppongo che potrebbe risultare nteressante per parecchi traduttori e, con le opportune modifiche, per molti freelance in altri settori. Questo ritengo sia fondamentale: deve essere un qualche cosa di usabile da più o meno tutti e adattabile. Ale. Paolo. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: icecube communication: progettazione e sviluppo siti internet, portali, e-commerce, servizi per la visibilità via Internet... il tuo business con noi cresce! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7351d=3-1 -- Alessandro Cattelan Freelance translator (EN, ES -- IT) http://www.proz.com/profile/76355 Tel.: (+39) 338 1823554 Skype: acattelan Yahoo! IM: alessandro.cattelan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
[EMAIL PROTECTED] ha scritto: Posso cominciare a fare delle osservazioni? 1) perchè hai creato due distinte tabelle per client e users? Non è + semplice usare un'unica tabella per tutti i soggetti e distinguerli poi con un campo bool o tinyint in client users collegues ecc? Ci ho dato un'occhiata veloce. Ho l'impressione che siano due distinte tabelle: i Clienti rappresentano chi ha commissionato il lavoro, i Colleghi chi ci sta lavorando. Non mi pare una buona idea unificare le Tabelle, anche in funzione di sviluppi futuri. 2) per ogni soggetto c'è la possibilità di indicare un solo indirizzo/recapito. Non è meglio svincolare la tabella degli indirizzi/recapiti da quella dei soggetti in modo che ad un singolo soggetto si possano aggiungere tutti i recapiti che si vuole (uno per Milano, uno per New York ecc)? Questo potrebbe andare bene, ma magari in una prima fase non è strettamente necessario. Mi guardo un pò lo schema e scrivo due righe. Potrebbe venirne fuori qualcosa di usabile. Credo che il problema più serio siano le stampe, ma può darsi che col nuovo generatore di report di Sun qualcosa si può fare. Ciao. -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo wrote: [EMAIL PROTECTED] ha scritto: Posso cominciare a fare delle osservazioni? 1) perchè hai creato due distinte tabelle per client e users? Non è + semplice usare un'unica tabella per tutti i soggetti e distinguerli poi con un campo bool o tinyint in client users collegues ecc? Ci ho dato un'occhiata veloce. Ho l'impressione che siano due distinte tabelle: i Clienti rappresentano chi ha commissionato il lavoro, i Colleghi chi ci sta lavorando. Non mi pare una buona idea unificare le Tabelle, anche in funzione di sviluppi futuri. secondo te non basta aggiungere un qualche cosa che distingua i clienti dai colleghi piuttosto che i fornitori o i prestatori d'opera ecc? Usando una sola tabella e distinguendo i vari soggetti si evita di avere due distinti archivi per i soggetti. Ma sicuramente se non ti pare una buona idea un qualche motivo serio che a me sfugge ce l'hai. Mi guardo un pò lo schema e scrivo due righe. Potrebbe venirne fuori qualcosa di usabile. Credo che il problema più serio siano le stampe, ma può darsi che col nuovo generatore di report di Sun qualcosa si può fare. speriamo in pro-mamma sun Ciao. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: In REGALO 'All the Good Thing' di NELLY FURTADO Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6616d=3-1
Re: [utenti] Idee per gestionale
[EMAIL PROTECTED] ha scritto: secondo te non basta aggiungere un qualche cosa che distingua i clienti dai colleghi piuttosto che i fornitori o i prestatori d'opera ecc? Usando una sola tabella e distinguendo i vari soggetti si evita di avere due distinti archivi per i soggetti. Ma sicuramente se non ti pare una buona idea un qualche motivo serio che a me sfugge ce l'hai. Diciamo che quando due Tabelle hanno scopi diversi, secondo me non è mai una buona idea unificarle, per quanto possano contenere gli stessi campi. Una flag comporta, per qualunque esigenza (selezione, immissione etc.) l'uso di una query che annulla il vantaggio di non duplicare gli archivi. Inoltre, quando si progetta un'applicazione, non si sa per certo in futuro quali informazioni potrà contenere una Tabella: magari ai colleghi può essere aggiunto un campo inutile per i clienti, ed allora si che si sprecherebbero bytes. Infine mi sembra che tra colleghi e clienti gli unici campi in comune siano quelli dell'indirizzo. Ciao. -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo wrote: [EMAIL PROTECTED] ha scritto: secondo te non basta aggiungere un qualche cosa che distingua i clienti dai colleghi piuttosto che i fornitori o i prestatori d'opera ecc? Usando una sola tabella e distinguendo i vari soggetti si evita di avere due distinti archivi per i soggetti. Ma sicuramente se non ti pare una buona idea un qualche motivo serio che a me sfugge ce l'hai. Diciamo che quando due Tabelle hanno scopi diversi, secondo me non è mai una buona idea unificarle, per quanto possano contenere gli stessi campi. Una flag comporta, per qualunque esigenza (selezione, immissione etc.) l'uso di una query che annulla il vantaggio di non duplicare gli archivi. Inoltre, quando si progetta un'applicazione, non si sa per certo in futuro quali informazioni potrà contenere una Tabella: magari ai colleghi può essere aggiunto un campo inutile per i clienti, ed allora si che si sprecherebbero bytes. Infine mi sembra che tra colleghi e clienti gli unici campi in comune siano quelli dell'indirizzo. ok quindi tabelle diverse. Allora tabelle diverse sia per persone fisiche che giuridiche (tutti i tipi di società). Che condividono l'accesso ad una tabella in cui sono riportati i soli indirizzi e recapiti? La cosa mi porta ad un'ulteriore domanda: se poi si vuol cercare un nominativo di un soggetto fra tutte le tabelle, è possibile senza complicarsi la vita? ciao -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: In REGALO 'All the Good Thing' di NELLY FURTADO Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6616d=3-1
Re: [utenti] Idee per gestionale
[EMAIL PROTECTED] ha scritto: ok quindi tabelle diverse. Allora tabelle diverse sia per persone fisiche che giuridiche (tutti i tipi di società). Che condividono l'accesso ad una tabella in cui sono riportati i soli indirizzi e recapiti? Scusami, rischiamo di andare OT. Mi spiego meglio con un esempio. Una Tabella Clienti ha lo scopo di contenere tutti i miei Clienti. Se mi interessa la natura giuridica, posso mettere un Flag che mi permette di fare delle selezioni. Ma sempre Clienti sono. La Natura Giusridica è una classificazione. Colleghi e Clienti non hanno niente in comune, neppure lo scopo dell'archiviazione. Solo alcuni campi uguali, nemmeno tutti. La cosa mi porta ad un'ulteriore domanda: se poi si vuol cercare un nominativo di un soggetto fra tutte le tabelle, è possibile senza complicarsi la vita? E perchè dovrei cercare un nominativo in TUTTE le Tabelle? Se è un Cliente lo cerco nei Clienti, e così via. La struttura logica di un Database è il primo passo per scrivere applicazioni funzionanti. Meno Record ci sono in una Tabella, più veloce va il Software. Meno query scrivo, meno parametri uso, meno problemi ho. Questo è quello che penso io, poi tutti siamo liberi di fare come ci pare Ciao -- Filippo Cerulo blog: http://6of9.softcombn.com/ e-mail : [EMAIL PROTECTED] web : www.softcombn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Filippo Cerulo ha scritto: ... E perchè dovrei cercare un nominativo in TUTTE le Tabelle? Se è un Cliente lo cerco nei Clienti, e così via. Riporto la mia esperienza al riguardo: Io, nel mio db per l'azienda, ho una sola tabella con clienti e fornitori, quando faccio una fattura registro id_destinatario e id_mittente, in questo modo riesco a fare la contabilita' di piu' aziende senza problemi. (non che lo usi... ma l'ho utilizzato ...) Mi trovo bene e trovo comodo che dati omogenei siano nella stessa tabella. Quello che oggi e' un cliente domani e' un fornitore e quindi una tabella e' comoda. La struttura logica di un Database è il primo passo per scrivere applicazioni funzionanti. Meno Record ci sono in una Tabella, più veloce va il Software. E questa affermazione va contro la mia struttura che per forza di cose contiene piu' record di due tabelle separate, comunque trovo strano duplicare i dati solo perche' la stessa azienda e' ora fornitore e ora cliente. Ciao Picchio -- Picchiottino Roberto - Monte Bianco TLC - Courmayeur #160087 - http://counter.li.org/ Jabber: [EMAIL PROTECTED] - icq: 239063259 http://www.gnu.org/philosophy/no-word-attachments.it.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
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]
Re: [utenti] Idee per gestionale
Picchiottino Roberto ha scritto: Filippo Cerulo ha scritto: ... E perchè dovrei cercare un nominativo in TUTTE le Tabelle? Se è un Cliente lo cerco nei Clienti, e così via. Riporto la mia esperienza al riguardo: Io, nel mio db per l'azienda, ho una sola tabella con clienti e fornitori, quando faccio una fattura registro id_destinatario e id_mittente, in questo modo riesco a fare la contabilita' di piu' aziende senza problemi. (non che lo usi... ma l'ho utilizzato ...) Mi trovo bene e trovo comodo che dati omogenei siano nella stessa tabella. Quello che oggi e' un cliente domani e' un fornitore e quindi una tabella e' comoda. La struttura logica di un Database è il primo passo per scrivere applicazioni funzionanti. Meno Record ci sono in una Tabella, più veloce va il Software. Mica tanto vero... in termini di inserimenti e cancellazioni siamo nell'ordine di O(1) e quindi non dipende dal numero di record, per cui in generale bisognerebbe tendere a migliorare i tempi di ricerca (query) che risentono si del numero di record ma risentono ancor di più se per eseguire una query bisogna fare un join su più tabelle. Poi bisogna considerare se l'applicazione è da gestire sul client o sul server o tutta sullo stesso PC. E questa affermazione va contro la mia struttura che per forza di cose contiene piu' record di due tabelle separate, comunque trovo strano duplicare i dati solo perche' la stessa azienda e' ora fornitore e ora cliente. Concordo, e per quanto riguarda i db si dovrebbe tentare di non duplicare dati o la struttura dei record (così si modifica in un sol posto male che vada). Ciao Picchio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Idee per gestionale
Micron Engineering wrote: 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. l'idea originaria era di fare un mini gestionale (funzionale) in OOo. Forse stiamo andando OT, anche per colpa mia. A me queste discussioni fanno anche piacere perchè son comunque fonte di novità, di apprendimento. Paolo -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Un prestito supertasso zero spese? Oggi con Finatel è realtà. Puoi ottenere fino a 50.000 anche in 24 ore. Scopri Come * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7370d=4-1
Re: [utenti] Idee per gestionale
Alessandro Cattelan wrote: Per dare un seguito a quanto proposto in una precedente discussione, ho caricato alla seguente pagina uno schema dei campi e delle tabelle che dovrebbe contenere il database a cui pensavo: http://www.alessandrocattelan.it/XYZ/db.pdf (è un file pesantuccio e forse un po' confuso, ma al momento non sono riuscito a fare di meglio) Posso cominciare a fare delle osservazioni? 1) perchè hai creato due distinte tabelle per client e users? Non è + semplice usare un'unica tabella per tutti i soggetti e distinguerli poi con un campo bool o tinyint in client users collegues ecc? 2) per ogni soggetto c'è la possibilità di indicare un solo indirizzo/recapito. Non è meglio svincolare la tabella degli indirizzi/recapiti da quella dei soggetti in modo che ad un singolo soggetto si possano aggiungere tutti i recapiti che si vuole (uno per Milano, uno per New York ecc)? Vabbe', forse voglio troppo, ma credo sarebbe molto utile e suppongo che potrebbe risultare nteressante per parecchi traduttori e, con le opportune modifiche, per molti freelance in altri settori. Questo ritengo sia fondamentale: deve essere un qualche cosa di usabile da più o meno tutti e adattabile. Ale. Paolo. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: icecube communication: progettazione e sviluppo siti internet, portali, e-commerce, servizi per la visibilità via Internet... il tuo business con noi cresce! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7351d=3-1