Utilizzo di un ID master in SQL per unire tipi di elementi diversi

Question

Utilizzo di un ID master in SQL per unire tipi di elementi diversi

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

1

Sto progettando tabelle in sql per un piccolo sistema di ticketing. Una delle richieste è che un utente / agente possa pubblicare un ticket per un dipartimento o un agente.

Ora se ho una tabella genitore figlio in cui ogni agente appartiene a un dipartimento, finirei con una limitazione che un agente potrebbe essere assegnato a un dipartimento. Non credo sarebbe una buona idea per un bambino avere più genitori.

In pratica sono bloccato a questo punto poiché ogni ticket avrebbe un assegnatario sotto forma di AssigneeID. L'unica opzione che mi viene in mente è creare tre tabelle

table Agents
columns AgentID, AssigneeID

table Departments
columns DepartmentID, AssigneeID

table Assignees
columns AssigneeID, AssigneeTypeID

da dove otterrei l'identificativo univoco e più tardi cercherò di connetterlo al dipartimento o ad un agente.

C'è un modo migliore per farlo?

sql

posta John 19.05.2015 - 17:33

fonte

2 risposte

Leggi altre domande sui tag sql

Qual è la differenza tra un metodo Factory e Entity Translator Sincronizza i dati lato client dopo l'invocazione del servizio in ZPS

score 1 · Answer 1

Se gli agenti non avevano associazioni con il dipartimento, lo farei:

table Agents
AgentID PK

table Departments
DepartmentId PK 

table Tickets
AssigneeID FK to (AgentID OR DepartmentId)
AssigneeType ('Agent' or 'Department')

Quindi puoi fare:

Select 
     t.*
     ,coalese(a.name,d.name) as AssigneeName
from Tickets t
left join Agents a on a.AgentID =t.AssigneeID and t.AssigneeType ='Agent'
left join Departments d on d.DepartmentId=t.AssigneeID and t.AssigneeType ='Department'

Ma la mia comprensione della tua descrizione è che un agente fa parte di un dipartimento. Per questo motivo penso che il tuo design dovrebbe essere il seguente:

table Departments
DepartmentID PK

table Agents
AgentID
CurrentDepartmentID FK

table Tickets
AgentID FK (Optional)
DepartmentID FK (Required)

Se l'utente seleziona e Agent, il DepartmentID deve essere compilato automaticamente dal CurrentDepartmentID dell'agente. Il motivo per cui non si limitano a estrarre questi dati tramite un join è perché un agente può spostare i reparti e il ticket deve rimanere con il reparto anche con le mosse dell'agente.

score 0 · Answer 2

Ci sono un certo numero di opzioni:

1) usa un UNIQUEIDENTIFIER per il campo di assegnazione del Biglietto. Ogni Assegnabile avrebbe bisogno di avere il proprio UNIQUEIDENTIFIER per collegarli. Nulla davvero per mantenere UUID unici tra le due tabelle, però.

2) la tabella genitore / figlio potrebbe essere multiplexata:

Il TicketId ha un vincolo UNIQUE su di esso, in modo che possa essere assegnato al massimo una volta sola. Esiste un campo AgentId e DepartmentId campi nullable e un vincolo di controllo per garantire che solo uno di essi sia impostato alla volta.

Se un ticket DEVE essere assegnato, inserisci semplicemente i campi DepartmentId e AgentId nel ticket stesso.

Al contrario ... se aggiungi un terzo tipo di cosa che è assegnabile, devi aggiungere colonne a una tabella che probabilmente avrà molte righe.

3) tabella per tipo (che è sostanzialmente ciò che stai suggerendo nel tuo post)

Il ticket ha (come minimo) un Id e un AssignmentType. C'è un PK su Id e un UQ su Id e AssignmentType.

AssignmentType è FK per una tabella denominata AssignmentTypes, che contiene solo ID con record 1 e 2 in esso.

Altre due tabelle: AgentAssignment: (Id (FK- > Ticket.Id), AssignmentType come 1 PERSISTED NOT NULL, AgentId) DepartmentAssignment (Id (FK- > Ticket.Id), AssignmentType come 2 PERSISTED NOT NULL, DepartmentId)