sistema de correio interno estruturação

Question

Eu tenho duas tabelas no meu banco de dados:

• mesa Company (ID, CompanyName, CompanyUsername, CompanyPassword)
• tabela de funcionários (ID, CompanyID, nome, nome de usuário, senha)

Agora eu estou projetando um sistema de correio interno para que os funcionários possam escrever uns aos outros, mas também escrever diretamente para a conta da empresa.

A minha mesa e-mail interno tem esses campos:

• ID
• FromID
• ToID
• Mensagem
• ...

Agora o meu problema ocorre, quando eu preencher a tabela a mensagem com o ID (De / Para) eu não tenho idéia se a mensagem é de que a empresa ou o empregado como o poder ID existe em ambas as tabelas.

O que poderia minha solução ser?

Atualizar

O exemplo acima foi simplificar a minha pergunta.

As mesas dos funcionários e da empresa não contém nome de usuário ou senha, mas uma referência para uniqueidentifier adesão da ASP.NET para o gerenciamento de logins. Como sugerido abaixo com o uso da interface do usuário para controlar a partir de e o receptor, eu vou com UI do controlador ASP.NET Membership. Obrigado. : -)

Answer 1

Use um uniqueidentifier para id no mesas e uso newid a empresa eo empregado () como o valor padrão.

Como alternativa, Mesclar as tabelas e adicionar um campo para mostrar se o registro é uma empresa ou do empregado.

Answer 2

Você pode usar duas chaves estrangeiras, sobre a empresa e um para funcionários e garantir que apenas um é sempre definido.

Answer 3

Assim, um email.ToID poderia se referir a employee.ID ou company.ID, não é mesmo? Você não pode declarativamente restringir esse email.ToID deve existir em pelo menos um dos (employee.ID ou company.ID). Algumas soluções:

1. Tem IDs na tabela de e-mail (ToEmployeeId, ToCompanyId), e uma restrição de verificação que constrange que apenas um pode ser especificados em um determinado e-mail.
2. Tem Employee and Company IDs no mesmo espaço id, por exemplo, sua Id é dominado em algum tipo de contato mesa, e, em seguida, company.Id e employee.Id ambos têm uma FK referência para Contact.Id. Eu não acho que esta solução é muito bom já que o contato é um tipo muito manco Super dessas outras tabelas.
3. Ter uma mesa de contato como (ContactId, EmployeeId, CompanyId). Quando um e-mail é girado até EmployeeId = X, você olha para uma linha de contato com EmployeeId = X. Se não existir, criá-lo e usar o novo ContactId. O mesmo vale para CompanyID. Isso não permite-lhe expandir a usar outros conjuntos Id no futuro, bem