Newsgroup: it.comp.appl.access
Titolo: Regole per Creare un database ?

Ciao a tutti, (Roberto, Emyr, Maurizio Borelli, @Alex, e tutti quelli che mi
conscono e non).
Sto per fare una domanda che susciterà un po' di perplessità nei miei
confronti.
Ho deciso di rifare da zero un database gestionale che ho realizzzato in 7
mesi di lavoro.
In questi 7 mesi di lavoro ho imparato tante cose, molte da solo , leggendo
qua' e la', e molte altre ancora (per la maggioranza) tramite il sito comune
ed il vostro aiuto.
Nel mio vecchio db ho parecchie tabelle, tra le quali
Clienti,Fornitori,Idraulici,Dipendenti (queste sono le interessate della
domanda).
Secondo voi è meglio creare una unica tabella chiamata Clienti per
raggruppare sia i Clienti(privati) che gli Idraulici (società di idraulici)
?
Secondo voi è giusto raggrupparli in una unica tabella dove basta aggiungere
un campo in più nel quale si specifica se è un idraulico o un cliente ?
La tabella contterrà molti record (circa 2000 e oltre).
I campi della tabella sono i seguneti :
(Nome,via,città,prov,cap,tel1,tel2,numverde,fax,internet,email,banca
appoggio,abi,cab,indicazioni stradali,referente,cellulare,codfiscale)
Non so se dico una cazzata, ma cosa è meglio fare ?
Un altra domanda : gli indici Voi li usate ? Quali sono i vantaggi e dove
conviene realmente usarli ? Indici multipli sono convenienti ?
Per ora vi ringrazio, io intanto continuo a ri-creare.
Con simpatia.
Marco.
PS: Se qualcuno può indicarmi qualche documentazione che spiega come
strutturare logicamente un database in base ai dati che deve contenere sarei
grato.
Ciao.

 ha scritto nel messaggio
news:YjXx9.120853$%M1.
3108181
@twister2.libero.it...

Beh, per progettare un DATABASE occorre tenere sempre presenti le regole
fondamentali dei DB per l'ottimizzazione delle tabelle, e dei campi in esse
contenuti in modo da evitare doppioni inutili e problematici da trattare.
Quest'argomento è trattato nelle prime pagine di qualsiasi libro dedicato ai
DB
e si basa fondamentalmente su:
TABELLE, UNIVOCITA' dei dati e INDICI.
Dal tema Tabelle nasce tutta la TEORIA dei livelli di NORMALIZIONE, che
ben pochi usano e pochissimi sanno che esiste...........!!!
Per il tuo problema io unirei i dati in quanto simili, il campo da
aggiungere è
ovviamente necessario, e ti da la flessibilità di poter inserire in futuro
una nuova
tipologia di UTENTI identificato per il campo che andrai ad aggiungere.
Gli indici sono necessari per velocizzare le ricerche, le QRY, sopratutto in
un DB
Referenziale.
@Alex.


Grazie molte Alex,
quindi se io dovessi aggiungere un campo in questa tabella Clienti (che poi
contterrà clienti,idraulici e qualsiasi altra tipologia di clienti che
sfrutta la struttura esistente della tabella) e lo chiamo "tipocli"  nel
quale verrà memorizzato un identificativo che fa capire di che tipo è il
cliente io risolverei il problema.
Secondo voi è corretto gestire la cosa tramite una maschera principale sulla
quale esistono 2 pulsanti (per esempio) : Clienti e Idraulici.
Se io premo il pulsante Clienti lui mi apre la maschera Anagrafica (che fa
capo alla tabella Clienti) e inserisce un valore nel campo "tipocli".
Ma come faccio a fare cio' se è corretto fare in questo modo ? Mi spiego ,
su evento click del pulsante clienti eseguo me!tipocli ="cliente".
Ma se poi inserisco un altro cliente dalla maschera precedentemente aperta ,
come faccio a fargli capire ch sto inserendo un cliente ?
Per quanto riguarda gli indici, io dovre allora selezionare quei campi di
uso frequente ed indicizzarli, come se fosse un libro con il relativo
indice, dal quale accedo senza sfogliare tutto il libro , direttamente a
cio' che mi occorre ?
Fatemi sapere la vostra opinione. Sono ben accetti i consigli. Io sto
rifacendo questo db perhè trovo che posso farlo in modo migliore e più
scorrevole. (la maschera clienti ci metteva circa 10 secondi ad aprirsi
usando un ATHLON 1200 con 512 MB ram)
Grazie ancora.
Un saluto con simpatia
Marco

 come faccio a fargli capire ch sto inserendo un cliente ?
[CUT]
Per il numero di RECORDS che hai dichiarato sinceramente mi sembrano troppi
10s.
Ma mi sembra che ti stai complicando la vita.....!
Se sfrutti le proprietà di MASCHERA tipo Me.Filter="CampoClienti =
'Idraulici'"
oppure altro......!!!
Oppure riempi una Combo(Elenco Valori......) con il Tipo di Cliente da
selezionare e fai comporre
la stringa di FILTRO leggendo la Combo su evento AFTER_UPDATE ed eseguendo
il REQUERY della FORM.
Ci sono mille modi.
Prova a dare un'occhiata alle ottimizzazioni gestite da ACCESS, ti crea
gl'indici dove servono
e ti suggerisce alternative alcune volte valutabili....!!!
@Alex.