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
--- [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
--- 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
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,
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
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
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
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
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
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,
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
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
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
[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
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
[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
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
--- 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
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
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
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
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 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
[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
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.
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à,
[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
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
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:
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
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:
[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
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
[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
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
[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
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
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
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
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
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
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
42 matches
Mail list logo
