Scegliere la foreign_key

[som]

Ciao a tutti,

sono alle prese con un db e ho un dubbio sulla scelta della foreign_key .

Prendendo un classico esempio azienda-dipendente in cui :

Azienda ha i seguenti campi:
- IdAzienda
- NomeAzienda
- Città

mentre Dipendente:
- IdDipendente
- Nome
- Ruolo
- Azienda

Nella tabella Dipendente Azienda è la chiave che tiene in vita la relazione tra le due tabelle ma il dubbio è il seguente:

- Conviene utilizzare il campo IdAzienda? Se però poi cancello il record IdAzienda dovrò
scegliere: o cancello i relativi record Dipendenti o permetto che il campo rimanga Null.. ci sono alternative?

- Conviene utilizzare NomeAzienda (che è un indice non ripetuto) ? In questo modo se dovessi cancellare il record relativo all'azienda mi rimarrebbe comunque la stringa per me significativa..

Dico cretinate?! Qual'è il modo giusto di operare?

:master:


Grazie a tutti

[comas17]

mah, un paio di considerazioni...

1) Perchè pensi/devi cancellare il record di IdAzienda ? se (come in questo caso) hai altri dati che dipendono dal record che vuoi cancellare, semplicemente NON cancellarlo ed utilizza altre modalità per indicarlo come "cancellato" (ad esempio un campo aggiuntivo "stato") in modo che il legame resti comunque presente

2) Io riporterei semplicemente anche nella tabella dei dipendenti il campo IdAzienda (che ovviamente in questo caso potrà ripetersi in vari record) che ti legherà ogni dipendente alla propria azienda.
Con una banale join potrò poi recuperare il nome dell'azienda di ogni dipendente senza bisogno di riportarmi anche in questa tabella il nome "esplicito" che duplicherebbe inutilmente i dati e costringerebbe a doppi aggiornamenti (immagina il nome di un'azienda che passa ad esempio da srl a spa)

[som]

grazie comas17 per la risposta velocissima.

1) Perchè pensi/devi cancellare il record di IdAzienda ? se (come in questo caso) hai altri dati che dipendono dal record che vuoi cancellare, semplicemente NON cancellarlo ed utilizza altre modalità per indicarlo come "cancellato" (ad esempio un campo aggiuntivo "stato") in modo che il legame resti comunque presente

1) Ottimo suggerimento. Non penso di dover fare delle cancellazioni di questo tipo, ma mi sto facendo delle domande su come realizzare al meglio il database.

2) Io riporterei semplicemente anche nella tabella dei dipendenti il campo IdAzienda (che ovviamente in questo caso potrà ripetersi in vari record) che ti legherà ogni dipendente alla propria azienda.
Con una banale join potrò poi recuperare il nome dell'azienda di ogni dipendente senza bisogno di riportarmi anche in questa tabella il nome "esplicito" che duplicherebbe inutilmente i dati e costringerebbe a doppi aggiornamenti (immagina il nome di un'azienda che passa ad esempio da srl a spa)

Esattamente quello che ho fatto. Il mio dubbio non era tra l'inserimento sia dell'IdAzienda che del nomeAzienda ma l'uno o l'altro. Da quello che mi hai scritto capisco che usare l' Id è la soluzione migliore... anche perchè in caso di cambio nome sarebbe un bel caos

[mosquito70]

Originariamente inviato da som
grazie comas17 per la risposta velocissima.

1) Ottimo suggerimento. Non penso di dover fare delle cancellazioni di questo tipo, ma mi sto facendo delle domande su come realizzare al meglio il database.

Esattamente quello che ho fatto. Il mio dubbio non era tra l'inserimento sia dell'IdAzienda che del nomeAzienda ma l'uno o l'altro. Da quello che mi hai scritto capisco che usare l' Id è la soluzione migliore... anche perchè in caso di cambio nome sarebbe un bel caos

Non solo.
Ma sprechi anche spazio. Infatti utilizzando anche il nome Azienda, tra l'altro un varchar, ti porti dietro una quantita' di dati inutili.

Altra considerazione riguardo al punto 1.
Se cancelli l'azienda che senso ha tenere i dipendenti? Logicamente, o associ i dipendenti ad un altra azienda (update sull'id_azienda) o cancelli definitivamente anche loro.

Infine, utilizza lo stesso nome del campo id_azienda, sia sulla tabella dei dipendenti, che su quella dell'anagrafica azienda. Ti tornera' utile nel caso di Join (left join)

[comas17]

Originariamente inviato da mosquito70

Altra considerazione riguardo al punto 1.
Se cancelli l'azienda che senso ha tenere i dipendenti? Logicamente, o associ i dipendenti ad un altra azienda (update sull'id_azienda) o cancelli definitivamente anche loro.

Vero
Se tieni comunque i dati sia dell'azienda (sia pure in stato "cancellato" ) che dei dipendenti puoi risalire ad esempio alla "storia" dei dipendenti, cioè a tutte le aziende in cui hanno lavorato...

Ammesso che ti interessi

[som]

L'idea è sempre quella di usare un solo campo per la relazione.

Ho fatto una prova, cioè ho legato le due tabelle con il campo NomeAzienda, solo con quello ( non ho usato l'IdAzienda).
Ho specificato nelle regole di aggiornamento (sql managment studio) Sovrapponi.

In questo modo se modifico il NomeAzienda dalla tabella Azienda la modifica viene automaticament riportata ai record dipendenti. ( Un update evitabile se avessi utilizzato l'IdAzienda)

Se cancelloun record aziendai record figli o mi vengono cancellati o i valori in NomeAzienda vengono settati a NULL.

Quindi l'unica differenza mi pare sia nello spazio utilizzato nvarchar contro int/bigint

Sicuramente la cancellazione del record azienda non ha senso ma il discorso mi interessa per capire

[mosquito70]

Originariamente inviato da som
L'idea è sempre quella di usare un solo campo per la relazione.

Ho fatto una prova, cioè ho legato le due tabelle con il campo NomeAzienda, solo con quello ( non ho usato l'IdAzienda).
Ho specificato nelle regole di aggiornamento (sql managment studio) Sovrapponi.

In questo modo se modifico il NomeAzienda dalla tabella Azienda la modifica viene automaticament riportata ai record dipendenti. ( Un update evitabile se avessi utilizzato l'IdAzienda)

Se cancelloun record aziendai record figli o mi vengono cancellati o i valori in NomeAzienda vengono settati a NULL.

Quindi l'unica differenza mi pare sia nello spazio utilizzato nvarchar contro int/bigint

Sicuramente la cancellazione del record azienda non ha senso ma il discorso mi interessa per capire

Non si fa cosi'.
Non si mette un campo descrizione come relazione.

Il discorso dello spazio occupato, potrebbe sembrarti banale e magari nella tua applicazione non lo noterai, ma perche' partire con il piede sbagliato, tra l'altro sapendo si sbagliare?

Insomma, se "ti interessa capire" ed imparare metti il codice come relazione.

[som]

Perfetto, era quello che volevo sapere.

Vi ringrazio per la disponibilità e la chiarezza