Newsgroup: it.comp.appl.access
Titolo: relazioni uno a uno

Ciao, sara' sicuramente denigratoria la VS risposta
ma come! ancora a chiedere questo?
Comunque ci provo:)) lo stesso
allora, secondo Voi se devo catalogare dei modelli ( auto, vestiti,
barche...) , i quali hanno numerose caratteristiche, ma solo una per tipo,
per es.:lunghezza, o anche, n° cavalli vapore,
e queste caratteristiche sono divisibili per gruppo tipo: dimensioni,
prestazioni, allora:
mi conviene fare delle tabelle separate per questi macroGruppi o no?
Sinceramente, e forse percio' sbaglio, penso, ma chi me lo fa fare, tuti
questi attribbuti essendo unici li scrivo in un'unica tabella, in fondo non
sono poi differenti da nome, cognome, cap
Perfavore mi fate un po' di chiarezza, anche solo un po' grazie
ciao

 ha scritto nel messaggio
news:MXYfb.12413$e6.4...@twister2.libero.it...

Devi fare 3 tabelle:
Modelli(1---00) Appoggio (00----1) Caratteristiche
Non è che devi per forza, così hai una struttura flessibile e normalizzata.
@Alex.

 Ciao, sara' sicuramente denigratoria la VS risposta
...non se ne vede il motivo

Non esiste una risposta univoca alla tua domanda e di volta in volta
(tenendo fermi alcuni punti fondamentali), devono essere valutate diverse
cose per stabilire quale sia la migliore soluzione per la struttura da
creare.
Una delle regole fondamentali è quella di non avere informazioni ripetute,
anzitutto su + tabelle, poi nel 99% degli altri casi anche all'intererno
della stessa tabella.
Inoltre di solito è un bene quando all'interno di un record non vi siano
campi vuoti perchè non ha senso che in quel campo vi sia un valore.
Veniamo al tuo esempio, se hai una tabella articoli di magazzino, nella
quale confluiscono prodotti con caratteristiche molto diverse tra loro, puoi
seguire 3 strade: La prima prevede un campo con il tipo articolo, ed in base
al tipo vai a riempire certe caratteristiche anzichè altre.
La seconda prevede una tabella principale, con i dati che accomunano
qualsiasi articolo come il codice interno, la descrizione, ..., e la
categoria. Poi in base alla categoria si creano altre tabelle nelle quali
vengono imputate le caratteristiche peculiari della categoria.
La terza strada è quella suggerita da Alessandro, nella quale esiste una
tabella con gli articoli, una tabella con le caratteristiche possibili, ed
una tabella intermedia nella quale poter attribuire una qualsiasi
caratteristica ad un qualsiasi articolo senza alcun riferimento alla
categoria di appartenenza.
Nessuna delle 3 strade è la migliore, la prima è molto comoda e veloce da
implementare, ed è consigliabile se la tabella sarà riempita da pochi
record.
La seconda è consigliabile per un grande numero di record, con tipologie di
articoli ben definite.
La terza consente il maggior grado di flessibilità nel porre in relazione
caratteristiche ed articoli, con nessuno spreco di spazio, ma comporta la
maggiore complessità implementativa, inoltre per operare con grandi moli di
dati e soprattutto con molte caratteristiche attribuibili per articolo,
secondo me necessita di accorgimenti particolari per rendere veloce
l'inserimento dei dati.
Quindi: Di volta in volta occorre valutare con attenzione i pro ed i contro
delle varie soluzioni, tenendo conto delle possibili espansioni che
l'applicazione potrà subire.
Spero se non altro di non averti fatto maggior confusione.
Ciao.


non mi sembra chiaro
devo evitare record con molti campi vuoti?, cosa comporta questo? ho capito
bene?
potresti essere piu' esplicativo perfavore?
ringarzio ancora per la pazienza e che ben venga la confusione da chi tenta
di colmare la mia ignoranza
ciao

 non mi sembra chiaro
[CUT]
Come nel caso precedente sottolineo 'di solito'.
Se nello stesso archivio di prodotti metti insieme le gabbiette per gli
uccellini per le quali devi prevedere il campo: "NTrampoli", è chiaro che
questo campo non  avrà senso se l'articolo è una miscela zuccherina per la
quale deve essere inserita la "Densità" in °Baumè e viceversa.
Un'altro esempio superclassico è quello dell'anagrafica dove coesistono
persone fisiche e giuridiche, che hanno campi comuni, ma anche campi che
devono essere riempiti esclusivamente in base al tipo di anagrafica.
Facendo riferimento alle 3 possibilità di struttura che ti abbiamo indicato
io ed Alessandro  nei post precedenti, nel primo caso di una tabella unica
con un campo "TipoRecord" sul quale discriminare quali sono gli altri campi
da riempire oppure no, gli svantaggi sono che i  campi "per forza" vuoti
sprecano spazio e se occorre farci su dei raggruppamenti, somme, medie,
ricerche, ecc... le query si complicano e si rallentano. Tuttavia se ci sono
pochi record, la struttura del database è + semplice e le differenze di
velocità non si avvertiranno in alcun modo.
Ciao.

[CUT]
P.S.
E' da qualche giorno che mi sento poco normale e di qui i relativi consigli.


mi stupisce, tu che parli cosi' bene della normalizzazione :)
ciao e ancora mille grazie