Estructuración del sistema de correo interno.

Question

Tengo dos tablas en mi base de datos:

• Tabla de empresa (ID, CompanyName, CompanyUsername, CompanyPassword)
• Tabla de empleados (ID, ID de empresa, Nombre, Nombre de usuario, Contraseña)

En este momento estoy diseñando un sistema de correo interno para que los empleados puedan escribir entre ellos, pero también escribir directamente en la cuenta de la empresa.

Mi tabla de correo interno tiene estos campos:

• ID
• FromID
• ToID
• Mensaje
• ...

Ahora ocurre mi problema, cuando lleno la tabla de mensajes con ID (De / A) no tengo idea si el mensaje es de la compañía o del empleado, ya que la ID podría existir en ambas tablas.

¿Cuál podría ser mi solución?

Update

El ejemplo anterior fue para simplificar mi pregunta.

Las tablas de empleados y empresas no contienen nombre de usuario o contraseña, sino una referencia a la membresía de ASP.NET uniqueidentifier para administrar los inicios de sesión. Como se sugiere a continuación con el uso de UI para controlar el receptor y el receptor, voy con la interfaz de usuario del controlador de membresía ASP.NET. Gracias. :-)

Answer 1

Use un identificador único para la identificación en las tablas de Empresa y Empleado y use newid () como valor predeterminado.

Alternativamente, combine las tablas y agregue un campo para mostrar si el registro es una empresa o un empleado.

Answer 2

Puede usar dos claves externas, una para la empresa y una para el empleado, y asegurarse de que solo se configure una.

Answer 3

Entonces, un correo electrónico. ToID podría referirse a employee.ID o company.ID, ¿es correcto? No puede restringir declarativamente ese correo electrónico. ToID debe existir en al menos uno de (employee.ID o company.ID). Pocas soluciones:

1. Tener ID en la tabla de correo electrónico (ToEmployeeId, ToCompanyId) y una restricción de verificación que restringe que solo se pueda especificar uno en un correo electrónico determinado.
2. Tener ID de empleado y compañía en el mismo espacio de identificación, p. su ID se domina en algún tipo de tabla de contactos, y luego en company.Id y employee.Id tienen una referencia FK a Contact.Id. No creo que esta solución sea muy buena ya que Contact es un súper tipo bastante pobre de estas otras tablas.
3. Tener una tabla de contactos como (ContactId, EmployeeId, CompanyId). Cuando un correo se convierte en EmployeeId = X, busca una fila de contacto con EmployeeId = X. Si no existe, lo crea y utiliza el nuevo ContactId. Lo mismo vale para Companyid. Esto le permite expandirse para usar otros conjuntos de Id en el futuro también