Utilizzo dei tasti primari Autoincrement come chiavi esterne e codici univoci

Question

Utilizzo dei tasti primari Autoincrement come chiavi esterne e codici univoci

#1 da (2 voti)
#2 da (0 voti)

1

mi piacerebbe spingere di nuovo la discussione sullo stesso thread chiamato.

Uso anche le chiavi primarie auto incrementali come chiavi esterne, principalmente per tabelle di codici. Ogni riga ha anche un codice per identificare le voci per gli utenti (come ProductKey). Tutto funziona bene finché ho bisogno di un periodo di validità per le voci nelle tabelle di codice.

es. ogni cliente ha un BusinessAdvisor:

Client                              BusinessAdvisor     
Name        BusinessAdvisorID       ID Code Name        StartDate
Company1        1                   1   01  Schmidt     2017-04-01
Company2        4                   2   02  Müller      2017-01-01
Company3        2                   3   03  Schulze     2017-10-01
Company4        3                   4   11  Meyer       2016-05-01
Company5        1                   …
Company6        2                   48  02  Becker      2018-04-01
Company7        2

Al 2018-04-01 Müller lascia l'azienda e Becker ottiene il codice "02" e quindi tutti i clienti di Müller.

Per la cronologia di BusinessAdvisor non è consentito modificare la voce con ID 2. Questa riga ha terminato con l'impostazione di una data di fine.

In questo caso è possibile stampare Müller come BusinessAdvisor in rapporti storici (prima del 2018-04-01). Rapporti / display / elaborazione attuali dovrebbero mostrare / usare Becker, ma questa voce, ovviamente, usa un altro ID.

La mia opinione è di risolvere questo problema con una modifica della progettazione del database ...

Altre idee ???

WTI

sql database relational-database

posta wti 17.04.2018 - 17:20

fonte

2 risposte

Leggi altre domande sui tag sql database relational-database

REST Percorsi in base ai ruoli Come possiamo rendere Use Case Model in UML per una dichiarazione data?

score 2 · Answer 1

Se è necessario mantenere la chiave esterna allo stesso modo mi sembra che sia necessario un ulteriore table uno per il ruolo di advisor e quindi un altro per la persona che riempie il ruolo. La tabella delle persone avrebbe una chiave esterna che punta alla tabella dei ruoli. Ecco dove manterrai le date ecc.

Penso che sia molto meglio usare le chiavi primarie di riferimento nelle relazioni con le chiavi esterne. Fare riferimento a chiavi aziendali da una chiave esterna spesso causa problemi, nella mia esperienza.

score 0 · Answer 2

Sembra che il tuo consulente aziendale sia una posizione (potrebbe essere un territorio) a cui è assegnata una persona alla volta. Ci sarebbe un'altra tabella che gestisce questi incarichi, quindi persone diverse possono essere assegnate a quella posizione (Codice 2 in questo caso) in date di inizio diverse. La tabella delle assegnazioni è fondamentalmente una relazione molti-a-molti tra le persone e la posizione (Consigliere).

Questa struttura consente anche di assegnare una persona a due posizioni di Business Advisor contemporaneamente. L'azienda potrebbe non farlo regolarmente, ma potrebbe nel caso in cui qualcuno debba coprire finché non viene trovato un sostituto.

Altrimenti, modifica l'ID del consulente aziendale sul client, ma ora non hai cronologia delle assegnazioni.