Newsgroup: it.comp.appl.access
Titolo: Specifiche di Access 2003 - come superare i limiti

Ciao a tutti,
come noto, tra le specifiche di Access vi è la seguente: numero max di
indici per una tabella: 32.
Siccome ho la necessità di superare questo limite, ho pensato di
creare 2 tabelle legandole con una relazione 1 a 1.
Che ne pensate ?
Qualcuno sa se con Access 12 questi limiti verranno superati ?

 ha scritto nel messaggio 
news:1138034735....@g49g2000cwa.googlegroups.com...

Al momento non saprei dirti ma è uscito un libro che si intitola proprio
"Usare Access 2003 oltre ogni limite"
A te le conclusioni....:-)
Ciao
Roberto 

 "Usare Access 2003 oltre ogni limite"
L'ho appena comprato :-)


Ciao Mirko.
Cosi', tanto per sapere, cosa te ne fai di + di 32 indici
--
a.cara

 ha scritto nel messaggio 
news:Ie9Bf.46717$av6....@tornado.fastwebnet.it...

Gia!
Pensa che a me anche 32 sembrano parecchi:)
Morgan 

 Cosi', tanto per sapere, cosa te ne fai di + di 32 indici
Il problema è che in quella tabella ci sono molte chiavi esterne (che
Access computa assieme agli indici veri e propri nel computo del 32)


Sicuro allora di aver normalizzato bene?
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

Mirko Caporali ha scritto:

Mi autorispondo: ho fatto varie prove, tutto fila liscio.
Se avete altre idee, comunque, fatemi sapere.


Piu' o meno quello che pensavo (temevo).
Le idee sono quelle della risposta di Massimiliano.
A AMMP (acronimo italiano di IMHO) il tuo db viola la 1 Regola di 
normalizzazione, che sarebbe a dire, e' pensato come se fosse un foglio 
Excel
--
a.cara

"Mirko Caporali" <
Mi autorispondo: ho fatto varie prove, tutto fila liscio.
Se avete altre idee, comunque, fatemi sapere.
Hai letto le perplessità di MA e Alessandro Cara sulla struttura del tuo DB?
Ciao, Oscar

 Hai letto le perplessità di MA e Alessandro Cara sulla struttura del tuo DB?
Eccomi...
Non penso però di aver duplicato dei campi. Quella tabella è dalla
parte "molti" nella relazione con altre tabelle. Ogni campo fornisce
un'informazione diversa, non ricavabile dagli altri campi.


Il problema è
Se tu hai una tabella Automobili e scrivi
idAutomobile
Targa
Colore - Uno a molti con la tabella colore
cilindrata - uno a molti con la tabella cilindrate
Posti - uno  amolti con la tabella Posti
so tutte chiave esterne
In questo caso invece io ci vedo una tabella
Automobili
e una caratteristiche
con i campi
RifIdAuto - Caratteristica - valorecar
con due tabelle faccio tutto


 con due tabelle faccio tutto
Già... ma all'inizio non prevedevo tante "caratteristiche"


Allora la domanda è: perchè non rivedi la struttura dei dati?


 Allora la domanda è: perchè non rivedi la struttura dei dati?
bè... perchè ho visto che così gira senza problemi. E, allora,
perchè complicarsi la vita andando a modificare la struttura dei dati,
che significherebbe modificare queries, forms e reports ?

 che significherebbe modificare queries, forms e reports ?
Sicuramente,
ma iniziare cosě potrebbe portarti in vicoli ciechi se l'applicazione
cresce.
Normalemnte io ogni tot rivedo le mie applicazioni
e ti posso dire che per quanto possano essere ottimizzate esce sempre
qualcosa
Il problema di una frammentazione di dati del genere č quello di diventare
difficile
da gestire per le ricerche, il codice etc.
Sul codice io cerco di essere molto avaro e centralizzarlo il piů possibile.
ma questa č una mia scelta


 qualcosa
Verissimo...
A me succede che per quanto possa studiare a priori a tavolino, sorgono
sempre nuove necessità in corso d'opera. Tuttavia, al momento, non
vedo la necessità di apportare cambiamenti così drastici alla
struttura. 
In ogni caso, ti ringrazio per i suggerimenti.