subject:"\[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

2008-01-04 Per discussione Marco Quarona


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

2008-01-04 Per discussione pac

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

2008-01-04 Per discussione Marco Quarona


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-01-04 Per discussione pac

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

2008-01-04 Per discussione Davide Prina

--- 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

2008-01-04 Per discussione Picchiottino Roberto



[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