Strutturare il sistema di posta interno

Question

Ho due tabelle nel mio database:

• Tabella dell'azienda (ID, Nome azienda, Nome azienda, Password azienda)
• Tabella dei dipendenti (ID, ID azienda, nome, nome utente, password)

In questo momento sto progettando un sistema di posta interno per il quale i dipendenti possono scriversi, ma anche scrivere direttamente sull'account aziendale.

La mia tabella di posta interna ha questi campi:

• ID
• identità_mittente
• ToID
• Messaggio
• ...

Ora si verifica il mio problema, quando riempio la tabella dei messaggi con ID (Da / A) non ho idea se il messaggio provenga dalla società o dal dipendente poiché l'ID potrebbe esistere in entrambe le tabelle.

Quale potrebbe essere la mia soluzione?

Aggiorna

L'esempio sopra è stato quello di semplificare la mia domanda.

Le tabelle dei dipendenti e dell'azienda non contengono nome utente o password, ma un riferimento all'appartenenza ASP.NET uniqueidentifier per la gestione degli accessi. Come suggerito di seguito con l'utilizzo dell'interfaccia utente per controllare il da e il destinatario, vado con l'interfaccia utente dal controller di appartenenza ASP.NET. Grazie. : -)

Answer 1

Utilizza un identificativo univoco per ID nelle tabelle Società e Dipendente e usa newid () come valore predefinito.

In alternativa, unisci le tabelle e aggiungi un campo per mostrare se il record è una società o un dipendente.

Answer 2

È possibile utilizzare due chiavi esterne, su società e una su dipendente e assicurarsi che ne sia impostata solo una.

Answer 3

Quindi un'e-mail.ToID potrebbe riferirsi a employee.ID o company.ID, giusto? Non puoi vincolare in modo dichiarativo quell'e-mail. Il IDID deve esistere in almeno uno di (employee.ID o company.ID). Poche soluzioni:

1. Avere ID nella tabella e-mail (ToEmployeeId, ToCompanyId) e un vincolo di controllo che vincoli che solo uno può essere specificato su una determinata e-mail.
2. Hai ID dipendenti e società nello stesso spazio ID, ad es. il loro ID è masterizzato in una sorta di tabella di contatto, quindi in azienda. ID e impiegato. Entrambi hanno un FK che fa riferimento a Contact.Id. Non penso che questa soluzione sia molto buona poiché Contact è un super tipo piuttosto zoppo di queste altre tabelle.
3. Avere una tabella dei contatti come (ContactId, EmployeeId, CompanyId). Quando si invia una posta a EmployeeId = X, si cerca una riga di contatto con EmployeeId = X. Se non ne esiste uno, lo si crea e si utilizza il nuovo ContactId. Lo stesso vale per Companyid. Ciò consente di espandersi per utilizzare anche altri set di ID in futuro