Re: [utenti] Problema con importazione dati in OOoCalc
ciao io ho provato con vista salvando sia in unicode che in UTF-8 e mi si aprono entrambi tranquillamente spero di aver fatto la procedura giusta... Fabio Davide Prina ha scritto: Avrei bisogno di qualcuno che mi verifichi questo problema anche su altri sistemi operativi. Il problema è il seguente: se si importa un file in formato unicode e poi successivamente se ne deve importare uno in un altro un po' corposo in formato (es: ISO-8859-15) si può avere un blocco di OOo che può causare un "blocco/freeze" del sistema (occupazione di tutta la memoria disponibile, compreso lo swap ... con l'unica possibilità di uccidere il processo in esecuzione o X stesso nel caso di GNU/Linux). Il problema è che quando si sceglie una codifica di importazione (es: unicode) per importare un file, allora alla prossima importazione tiene l'ultima utilizzata; peccato però che se il file è in altro formato (es: ISO-8859-15) si ha che cerca di importare tutti i caratteri (anche se sono più su righe) su un'unica riga. ATTENZIONE: la procedura qui sotto potrebbe far bloccare il vostro sistema creando un freeze (potrebbe essere necessario uno spegnimento brutale a seconda del sistema operativo). Per riprodurre il problema: * creare un file di testo contenente qualcosa come: a,b,c,d,e,f,g,h,i 1,2,3,4,5,6,7,8,9 * salvare il file con nome 1.csv * aprire il file con OOo e indicare come codifica unicode * chiudere il file aperto con OOo * editare il file 1.csv con un editor di testo e aggiungere altre 8 righe: 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 * riaprirlo con OOo a questo punto l'apertura dovrebbe essere rallentata di molto, ma si dovrebbe riuscire ad arrivare alla schermata in cui si selezione il tipo di carattere e le modalità di importazione. Se però il numero di righe cresce (es: diventano 100 ... però penso dipenda anche da quanta RAM si ha a disposizione), allora non si arriverà alla schermata di importazione e il sistema resterà bloccato. Intanto provo a vedere se c'è già una issue sull'argomento 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Problema con importazione dati in OOoCalc
--- Andrea Pescetti ha scritto: > Davide Prina ha scritto: >> * creare un file di testo contenente qualcosa come: >> a,b,c,d,e,f,g,h,i >> 1,2,3,4,5,6,7,8,9 >> * salvare il file con nome 1.csv > > Creo il file da un editor di testo e, al momento di salvare > dall'editor, > imposto la codifica su Unicode UTF-8 o su ISO-8859-15 (ho provato > entrambi). io lo salvo in ISO-8859-15, ma non penso faccia differenza >> * aprire il file con OOo e indicare come codifica unicode >> * chiudere il file aperto con OOo > > Fin qui nessun problema, chiudo il file ma non chiudo OOo. ok >> * editare il file 1.csv con un editor di testo e aggiungere altre 8 >> righe: > Ho aggiunto altre 40.000 righe e salvato dall'editor impostando la > codifica su Unicode UTF-8 o su ISO-8859-15 (ho provato entrambi in > entrambi i casi detti sopra, quindi un totale di 4 prove). ecco qui dov'è la differenza, io non imposto "unicode UTF-8", ma imposto solo "unicode" se uso "unicode UTF-8" non ho nessun problema neppure io Da quello che mi dite sembra che voi non abbiate solo "unicode". UTF-8 è una codifica di caratteri unicode multi-byte (variabile da 1 a 4 byte) e compatibile con i caratteri ASCII, ma non è la codifica di caratteri unicode (che è fisso a 2 byte). Probabilmente voi non avete installato unicode sul vostro sistema. Probabilmente qualche giorno fa ho aperto qualcosa con "unicode" o oggi mentre stavo estraendo il thesaurus per i controlli non riuscivo a creare un file .ods per i volontari ... Quindi io in realtà le prove le ho fatto con l'estrazione del thesaurus che è un po' più complessa del file che ho indicato come esempio. 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] Problema con importazione dati in OOoCalc
Alle sabato 05 gennaio 2008, Davide Prina ha scritto: > > devi aver aperto già un file csv e impostato come tipo carattere > l'unicode prima di aprire quello con più di 100 righe. Ho salvato il file con KEdit con codifica ISO 8859-15. Poi con OOo: File --> Apri --> nella finestra "Importazione testo" trovo impostato la codifica "Uincod (UTF-8)" ed apro il file. > Poi dipende da > quanta RAM hai (io ho solo 500 MB) ... Ho 256 MB Ambro - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Problema con importazione dati in OOoCalc
Davide Prina ha scritto: > Per riprodurre il problema: Anch'io non riesco a riprodurlo, nonostante abbia provato con varie versioni di OOo. Rivediamo i passi. > * creare un file di testo contenente qualcosa come: > a,b,c,d,e,f,g,h,i > 1,2,3,4,5,6,7,8,9 > * salvare il file con nome 1.csv Creo il file da un editor di testo e, al momento di salvare dall'editor, imposto la codifica su Unicode UTF-8 o su ISO-8859-15 (ho provato entrambi). > * aprire il file con OOo e indicare come codifica unicode > * chiudere il file aperto con OOo Fin qui nessun problema, chiudo il file ma non chiudo OOo. > * editare il file 1.csv con un editor di testo e aggiungere altre 8 > righe: Ho aggiunto altre 40.000 righe e salvato dall'editor impostando la codifica su Unicode UTF-8 o su ISO-8859-15 (ho provato entrambi in entrambi i casi detti sopra, quindi un totale di 4 prove). > a questo punto l'apertura dovrebbe essere rallentata di molto E invece no, in circa 3 secondi mi trovo tutte le 40.000 righe senza alcun problema. Nota che OOo ogni volta mi richiede la codifica, ma anche se la metto sbagliata non ho problemi con il testo che hai indicato. Nota: per il testo che hai proposto, che e' ASCII, e' difficile che la codifica possa creare problemi: sia UTF-8 sia ISO-8859-1 codificano il file nel medesimo modo. Ciao, Andrea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Problema con importazione dati in OOoCalc
--- ambro ha scritto: > Alle sabato 05 gennaio 2008, Davide Prina ha scritto: >> Per riprodurre il problema: >> * creare un file di testo contenente qualcosa come: >> a,b,c,d,e,f,g,h,i >> 1,2,3,4,5,6,7,8,9 >> * salvare il file con nome 1.csv >> * aprire il file con OOo e indicare come codifica unicode >> * chiudere il file aperto con OOo >> * editare il file 1.csv con un editor di testo e aggiungere altre 8 > > Forse non ho capito la procedura, ma non ho nessun problema, anche > con più di 100 righe. devi aver aperto già un file csv e impostato come tipo carattere l'unicode prima di aprire quello con più di 100 righe. Poi dipende da quanta RAM hai (io ho solo 500 MB) ... penso che più RAM hai e più righe devi inserire per avere il blocco > OS Debian testing > OOo 2.2.1 anch'io sto usando Lenny 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] Problema con importazione dati in OOoCalc
Alle sabato 05 gennaio 2008, Davide Prina ha scritto: > Avrei bisogno di qualcuno che mi verifichi questo problema anche su > altri sistemi operativi. > > Per riprodurre il problema: > * creare un file di testo contenente qualcosa come: > a,b,c,d,e,f,g,h,i > 1,2,3,4,5,6,7,8,9 > * salvare il file con nome 1.csv > * aprire il file con OOo e indicare come codifica unicode > * chiudere il file aperto con OOo > * editare il file 1.csv con un editor di testo e aggiungere altre 8 Forse non ho capito la procedura, ma non ho nessun problema, anche con più di 100 righe. OS Debian testing OOo 2.2.1 editor KEdit ambro - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] [CALC] Celle "dinamiche"
On Jan 5, 2008 1:52 PM, HoX <[EMAIL PROTECTED]> wrote: > Avrei bisogno di modificare delle in modo un po' particolare nel senso > che: > > 2. dovrei fare in modo che una cella imposti il valore di un'altra con > una funzione tipo: "=LA_CELLA_DIVENTA(C3,"pippo")" impostando il valore > della cella C3 a "pippo"... e' possibile? > Ciao ancora, Non capisco molto bene questa richiesta, ma ho l'impressione che ti stia complicando la vita inutilmente... puoi fare un esempio di come useresti questa funzione? Qual'e' esattamente la parte variabile? la cella destinazione o il valore? e come controlli questa variabile? Ciao, Michele
Re: [utenti] [CALC] Celle "dinamiche"
On Jan 5, 2008 1:57 PM, Renato Ferrari <[EMAIL PROTECTED]> wrote: > Il 14:52, sabato 5 gennaio 2008, HoX ha scritto: > > Avrei bisogno di modificare delle in modo un po' particolare nel senso > che: > > 1. dovrei fare in modo di poter usare riferimenti del tipo C(B3) dove se > > il valore della cella B3 è 2 il risultato è C2 > > una cosa così nella barra della formula: > ="c"&D4 > può andare? > ogni modifica in D4 si ripercuote nella cella con la formula > > > -- > Linux Registered User #219791 > Linux Registered Machine #104061 > [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Non sono molto pratico di calc, ma secondo me (senza aver provato) devi giocare con indirect (la funzione a cui puoi passare un riferimento scritto come testo) o address per generare il riferimento. Ad esempio: in A1000 (cella di "appoggio" scrivi quello che ti ha detto Renato, ma per avere poi il valore di C2 o C3 devi usare =Indirect(A1000) (credo) Se ho detto una bischerata (assai probabile) ignorami ;-) Ciao, Michele
[utenti] Problema con importazione dati in OOoCalc
Avrei bisogno di qualcuno che mi verifichi questo problema anche su altri sistemi operativi. Il problema è il seguente: se si importa un file in formato unicode e poi successivamente se ne deve importare uno in un altro un po' corposo in formato (es: ISO-8859-15) si può avere un blocco di OOo che può causare un "blocco/freeze" del sistema (occupazione di tutta la memoria disponibile, compreso lo swap ... con l'unica possibilità di uccidere il processo in esecuzione o X stesso nel caso di GNU/Linux). Il problema è che quando si sceglie una codifica di importazione (es: unicode) per importare un file, allora alla prossima importazione tiene l'ultima utilizzata; peccato però che se il file è in altro formato (es: ISO-8859-15) si ha che cerca di importare tutti i caratteri (anche se sono più su righe) su un'unica riga. ATTENZIONE: la procedura qui sotto potrebbe far bloccare il vostro sistema creando un freeze (potrebbe essere necessario uno spegnimento brutale a seconda del sistema operativo). Per riprodurre il problema: * creare un file di testo contenente qualcosa come: a,b,c,d,e,f,g,h,i 1,2,3,4,5,6,7,8,9 * salvare il file con nome 1.csv * aprire il file con OOo e indicare come codifica unicode * chiudere il file aperto con OOo * editare il file 1.csv con un editor di testo e aggiungere altre 8 righe: 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 1,2,3,4,5,6,7,8,9 * riaprirlo con OOo a questo punto l'apertura dovrebbe essere rallentata di molto, ma si dovrebbe riuscire ad arrivare alla schermata in cui si selezione il tipo di carattere e le modalità di importazione. Se però il numero di righe cresce (es: diventano 100 ... però penso dipenda anche da quanta RAM si ha a disposizione), allora non si arriverà alla schermata di importazione e il sistema resterà bloccato. Intanto provo a vedere se c'è già una issue sull'argomento 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] [CALC] Celle "dinamiche"
Il 14:52, sabato 5 gennaio 2008, HoX ha scritto: > Avrei bisogno di modificare delle in modo un po' particolare nel senso che: > 1. dovrei fare in modo di poter usare riferimenti del tipo C(B3) dove se > il valore della cella B3 è 2 il risultato è C2 una cosa così nella barra della formula: ="c"&D4 può andare? ogni modifica in D4 si ripercuote nella cella con la formula -- Linux Registered User #219791 Linux Registered Machine #104061 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[utenti] [CALC] Celle "dinamiche"
Avrei bisogno di modificare delle in modo un po' particolare nel senso che: 1. dovrei fare in modo di poter usare riferimenti del tipo C(B3) dove se il valore della cella B3 è 2 il risultato è C2 2. dovrei fare in modo che una cella imposti il valore di un'altra con una funzione tipo: "=LA_CELLA_DIVENTA(C3,"pippo")" impostando il valore della cella C3 a "pippo"... e' possibile? Per fare tutto cio' vorrei evitare di usare macro -- "Coltiva Linux, tanto Windows si pianta da solo" - Anonimo "Se qualcosa può andar male, lo farà" - Murphy's Law Untrust the Trusted Computing - http://www.no1984.org NON AUTORIZZO LA MEMORIZZAZIONE DEL MIO INDIRIZZO SU OUTLOOK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Gestionale - tb indirizzi
[EMAIL PROTECTED] ha scritto:
...
>>
>> Per un cosi' ampio insieme di campi io farei tre tabelle, una con i
>> dati essenziali (anagrafica), una con il tipo di contatto
>> (tipo_contatto) e una con il contatto effettivo (contatto).
>>
>> anagrafica
>> - id
..
>> - privacy
>> - Ecc. ecc.
>> tipo_contatto
>> - id
>> - testo; ex {tel, wind, TI, 3, email, web, skipe, voip, via, ..}
>> contatto
>> - id
...
>> - testo
>> - ordine
>>
>> Poi le maschere ... sono un casino pero' troppi campi non mi piacciono...
>>
>> In questo modo la tabella contatti conterra' sicuramente molti record.
>> Io non ho mai visto una tabella con tanti campi tutti utilizzati in
>> tutti i record ...
>>
>
>
> giusto, è meglio dividere la tabella degli indirizzi dei contatti in
> almeno 3 diverse:
> - per gli indirizzi fisici
> - per i recapiti telefonici
> - per i recapiti/indirizzi internet
ATTENZIONE: la mia proposta non divide in tre tabelle come dici tu ma in
anagrafica, tipo e contennuto. Tutti i dati sono nel contenuto
(contatto), quindii quel "giusto" non e' giusto :-)
Ciao
Picchio
>
>
> bye
>
>
>
>
>
>
>
>
> --
> Email.it, the professional e-mail, gratis per te: http://www.email.it/f
>
> Sponsor:
> Raggiungi i tuoi potenziali clienti in tutto il mondo! Affidati ad
> icecube.it: professionalità ed esperienza per farti conoscere su Internet
> Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7350&d=5-1
>
--
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
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
Davide Prina ha scritto: > --- 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. > a maggior ragione le query sono indispensabili. Vorrei farti notare che con la mia struttura il database contiene complessivamente meno dati, riduce il numero degli indici, tutte le FK e le query sono eseguite sugli indici quindi le prestazioni sono le massime ottenibili. Quando parli di milioni di record comunque ti riferisci a soluzioni n-tier; in caso di db come MySql o MS SQL operando con i cursori lato server le operazioni vengono eseguite sul server e la mole di dati passate al client è minore infatti vengono passati solo i risultati della query ed il server è il posto migliore dove eseguire le elaborazioni. Quindi è pure facile il porting da standalone a n-tier. Nel caso di db e applicazione sullo stesso PC è funzione del tipo di db come gestisce i dati (es. da non seguire è Access) ma in linea di massima le query sono comunque più vantaggiose. > 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] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[utenti] Gestionale - specifiche
Ciao, hoo seguito tutta la discussione su come organizzare le tabelle per avere la maggiore efficienza e su come questa dipenda da svariati fattori. Mi sorgono spontanee alcune domande che spero siano spunti di riflessione: - un simil gestionale del genere quanti soggetti, comprendendo fornitori, clienti, collaboratori ecc, potrà mai avere? 1000, 1 - con numeri simili di record il discorso dell'efficienza e della velocità del DB sono effettivamente critici? - oppure è più critico organizzare i dati in maniera logica per l'umano e non per la macchina? bye P.S. La mia non è polemica, voglio capire con voi. Come ho già scritto in altre email da questa discussione imparo in ogni caso... -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: KILL BILL! scarica la colonna sonora del film: è in REGALO! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6614&d=5-1
Re: [utenti] Idee per gestionale
Filippo Cerulo ha scritto: > 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. Dai adesso non diciamo stupidaggini... tutt'al più devi scrivere 2 righe di codice > > Dipende in effetti dal Front End utilizzato, ed inoltre non è quasi > mai possibile (a meno di giri di valzer...) su query uno a molti. Insisto è solo questione di codice... > 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. Per definizione un record si riferisce solo ad una tabella; nella mia ipotesi per aggiungere un nuovo cliente devi aggiungere un nuovo record nella tabella clienti, un nuovo record nella tabella indirizzi e così via un record in tutte le tabelle in relazione con la tabella cliente (che abbia un senso per l'operazione che stai eseguendo dalla maschera). Considerando che l'inserimento di nuovi record in una tabella costa O(1) in n tabelle costa n * O(1) quindi le prestazioni sono comunque preservate. > Tutto per risparmiare campi? No, perchè strutturare i Db come si è > proposto in questa discussione non è certo un modello di semplicità Non risparmi dati, risparmi spazio disco e soprattutto sei più agile per modificare il db. Supponi che in seguito devi aggiungere ad es. un contatto skype che non avevi inizialmente previsto: devi modificare tutte le tabelle dov'è richiesto il dato. Nel mio caso devi solo aggiungere un tipo di contatto e quindi non devi nemmeno modificare la/e tabelle; se organizzi le maschere delle anagrafiche tipo master/dettagli (maschera + elenco dati o sottomaschera) per ogni tabella collegata dovrai solo aggiungere un controllo di testo o altro per il nuovo dato (se usi una griglia neppure quello). >> 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. Non era una critica (in ogni caso sarebbe costruttiva) ma un invito a pensare senza essere condizionati dalle "buone pratiche" presenti sui testi di basi di dati (ormai superati) e passare al pensiero object oriented che ha cominciato a farsi strada anche tra i db (vedi PostgreSql). > 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. Certo, modificare costa, progettare pensando alle modifiche future è un pò più lungimirante. > Ognuno ha il suo metodo, e io li rispetto tutti. Idem, se non volessi condividere la mia esperienza me ne starei zitto. > > Ciao. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [utenti] Gestionale - tb indirizzi
Picchiottino Roberto wrote:
[EMAIL PROTECTED] ha scritto:
Ciao,
i discorsi su come impostare il DB van bene... ma parliamo anche di
campi e dati.
Per la eventuale tabella indirizzi potrei suggerire una stuttura di
questo tipo (scusate la struttura di mysql e la denominazione dei campi
per la poca fantasia):
Premetto che non sono un esperto
Per un cosi' ampio insieme di campi io farei tre tabelle, una con i
dati essenziali (anagrafica), una con il tipo di contatto
(tipo_contatto) e una con il contatto effettivo (contatto).
anagrafica
- id
- id_padre (lo uso per strutturare l'anagrafica come un albero)
- Nome
- cognome (o denominazione ditta)
- PI
- CF
- privacy
- Ecc. ecc.
tipo_contatto
- id
- testo; ex {tel, wind, TI, 3, email, web, skipe, voip, via, ..}
contatto
- id
- id_tipo
- id_anagrafica
- testo
- ordine
Poi le maschere ... sono un casino pero' troppi campi non mi piacciono...
In questo modo la tabella contatti conterra' sicuramente molti record.
Io non ho mai visto una tabella con tanti campi tutti utilizzati in
tutti i record ...
giusto, è meglio dividere la tabella degli indirizzi dei contatti in
almeno 3 diverse:
- per gli indirizzi fisici
- per i recapiti telefonici
- per i recapiti/indirizzi internet
bye
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Raggiungi i tuoi potenziali clienti in tutto il mondo! Affidati ad icecube.it:
professionalità ed esperienza per farti conoscere su Internet
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7350&d=5-1
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=7110&d=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
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] numerazione pagina calc
Il 22:10, venerdì 4 gennaio 2008, lor ha scritto: > non ti dico quanto mi senta sciocco, mi ero fissato che la sai quante volte mi sono incartato per giorni a scervellarmi su un problema la cui, soluzione, poi, era banale come questa se non di più? > soluzione dovesse limitarsi a qualcosa da inserire come comando di > campo nel tab "pie di pagina", -- Linux Registered User #219791 Linux Registered Machine #104061 [EMAIL PROTECTED] - 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
--- "[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, 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]
