integrità referenziale
Pietro Crincoli
Stefano Bettini
""Pietro Crincoli"" <piero.c...@infoconsulting.it> wrote in message
news:001a01c069dd$357ac0e0$0201020a@Angela...
Grazie Pietro Crincoli
Certamente.
Bye, Ste
Pietro Crincoli
facoltativa? In altre parole, č possibile dire ad Access che una foreign key
abbia un valore corrispondente a una primary key di un'altra tabella oppure
null ?
Grazie Pietro Crincoli
Certamente.
Bye, Ste
La domanda era imprecisa. Se le due chiavi (foreign/primary) sono composte
da due campi, di cui uno obbligatorio e uno
facoltativo, posso ancora applicare l'integritą referenziale?
Non so se č chiaro, faccio un esempio:
La tabella Ordini ha la chiave esterna "societą, fattura" (che punta alla
tabella fatture). Il campo societą deve essere sempre valorizzato, il campo
fattura puņ avere valore Null. Access rifiuta di applicare l'integritą
referenziale sulla relazione ordini - fatture. O sbaglio ?
Ciao a tutti, spero in futuro di poter anche rispondere alle domande invece
di farne soltanto Pietro Crincoli
--
Posted from urano.wintec.it [195.135.34.162]
via Mailgate.ORG Server - http://www.Mailgate.ORG
Stefano Bettini
> La domanda era imprecisa. Se le due chiavi (foreign/primary) sono composte
> da due campi, di cui uno obbligatorio e uno
> facoltativo, posso ancora applicare l'integrità referenziale?
?? Una primary-key *NON* può avere un campo facoltativo, non ammette
null...
> Non so se è chiaro, faccio un esempio:
>
> La tabella Ordini ha la chiave esterna "società, fattura" (che punta alla
> tabella fatture). Il campo società deve essere sempre valorizzato, il
campo
> fattura può avere valore Null. Access rifiuta di applicare l'integrità
> referenziale sulla relazione ordini - fatture. O sbaglio ?
Bho? A naso direi di sì, ma bisognerebbe provare.
Sicuramente è la chiave per tabella fatture + stranache io abbia mai visto,
ed altrettanto sicuramente sarebbe sempre bene avere una chiave primaria
mono-campo su tutte le tabelle (sennò alla terza tabella relazionata ti
ritrovi una chiave primaria che ti occupa + spazio dei dati!!)
Ti posso dire cosa sicuramente funziona, se sulla tabella ordini hai la
chiave esterna
NumFattura che punta alla tabella fatture puoi tranquillamente impostare
l'integrità
referenziale tra fatture ed ordini anche lasciando il campo
Ordini.NumFattura a null.
Bye, Ste
Pietro Crincoli
> tabella fatture). Il campo società deve essere sempre valorizzato, il
campo
> fattura può avere valore Null. Access rifiuta di applicare l'integrità
> referenziale sulla relazione ordini - fatture. O sbaglio ?
Bho? A naso direi di sì, ma bisognerebbe provare.
Sicuramente è la chiave per tabella fatture + stranache io abbia mai visto,
ed altrettanto sicuramente sarebbe sempre bene avere una chiave primaria
mono-campo su tutte le tabelle (sennò alla terza tabella relazionata ti
ritrovi una chiave primaria che ti occupa + spazio dei dati!!)
Ti posso dire cosa sicuramente funziona, se sulla tabella ordini hai la
chiave esterna
NumFattura che punta alla tabella fatture puoi tranquillamente impostare
l'integrità
referenziale tra fatture ed ordini anche lasciando il campo
Ordini.NumFattura a null.
Bye, Ste
Perchè la chiave della tabella fatture (Società + NumFattura) è strana? Devo
gestire un sistema "multiazienda"
dove ogni società del gruppo ha i suoi ordini, le sue fatture... di
conseguenza la chiave primaria comprende quasi sempre la società... O
dovrei inventare una chiave primaria?
In ogni caso, sull'help di access, alla spiegazione di "chiave esterna" dice
"se una
chiave esterna consiste di più campi e uno
qualsiasi di questi è null, tutti i campi devono essere null". Però mi
sembra una limitazione molto pesante.
Pietro
Stefano Bettini
> Perchè la chiave della tabella fatture (Società + NumFattura) è strana?
Devo
> gestire un sistema "multiazienda"
> dove ogni società del gruppo ha i suoi ordini, le sue fatture... di
> conseguenza la chiave primaria comprende quasi sempre la società... O
> dovrei inventare una chiave primaria?
Come ti dicevo io metto sempre e comunque come chiave primaria un bel campo
numerico, se non ho un valore che fa al caso mio ci metto un contatore...
Come ti dicevo la scelta nasce dall'esigenza di non ritrovarsi poi "a valle"
delle
relazioni con chiavi primarie praticamente ingestibili (oltre che enormi in
termini di bytes),
oltre naturalmente a tutte le problematiche di sviluppo che avere un id
comunque
univoco ti risolve (in questo momento sviluppo con interfaccia web e credo
proprio
che mi sparerei se dovessi gestire nei link tabelle con indici multicampo!)
Comunque de-gustibus...
> In ogni caso, sull'help di access, alla spiegazione di "chiave esterna"
dice
> "se una
> chiave esterna consiste di più campi e uno
> qualsiasi di questi è null, tutti i campi devono essere null". Però mi
> sembra una limitazione molto pesante.
>
Onestamente anche a me, e mi risulta di difficile comprensione visto
che le chiavi non primarie sono "nullable" per definizione...
Ma hai provato se effettivamente le cose stanno così?
Và, mò provo e faccio sapè...
Bye, Ste
Stefano Bettini
"Stefano Bettini" <sbet...@iol.it> wrote in message
news:Ygn06.158367$DG3.3...@news2.giganews.com...
>
> Ma hai provato se effettivamente le cose stanno così?
>
> Và, mò provo e faccio sapè...
>
Confermo, effettivamente le cose stanno come dice l'help....
Brutta limitazione in effetti, ma ragione in più per mettere un id univoco.
Bye, Ste