Structuration du système de messagerie interne

Question

J'ai deux tables dans ma base de données:

• Table de société (ID, Nom de la société, Nom de la société, Mot de passe de la société)
• Table des employés (ID, CompanyID, Nom, Nom d'utilisateur, Mot de passe)

Je conçois actuellement un système de courrier interne pour lequel les employés peuvent s’écrire, mais aussi écrire directement sur le compte de la société.

Ma table de courrier interne contient les champs suivants:

• ID
• FromID
• ToID
• Message
• ...

Maintenant, mon problème survient lorsque je remplis la table des messages avec des identifiants (de / à), je n'ai aucune idée si le message provient de la société ou de l'employé, car l'identifiant peut exister dans les deux tableaux.

Quelle pourrait être ma solution?

Mettre à jour

L'exemple ci-dessus visait à simplifier ma question.

Les tables d'employé et d'entreprise ne contiennent ni nom d'utilisateur ni mot de passe, mais une référence à l'appartenance uniqueidentifier d'ASP.NET pour la gestion des connexions. Comme suggéré ci-dessous avec l'utilisation de l'interface utilisateur pour contrôler le destinataire et le destinataire, je vais avec l'interface utilisateur à partir du contrôleur d'adhésion ASP.NET. Merci. : -)

Answer 1

Utilisez un identifiant unique pour id dans les tables Société et Employé et utilisez newid () comme valeur par défaut.

Vous pouvez également fusionner les tables et ajouter un champ indiquant si l'enregistrement est une entreprise ou un employé.

Answer 2

Vous pouvez utiliser deux clés étrangères, l'une pour l'entreprise et l'autre pour un employé, et vous assurer qu'une seule est définie.

Answer 3

Donc, un email.ToID pourrait faire référence à employee.ID ou company.ID, est-ce exact? Vous ne pouvez pas contraindre de manière déclarative cet email.ToID doit exister dans au moins un des éléments (employee.ID ou company.ID). Peu de solutions:

1. avoir des identifiants dans la table de courrier électronique (ToEmployeeId, ToCompanyId) et une contrainte de vérification qui contraint un seul d'entre eux à spécifier sur un courrier électronique donné.
2. Ayez les identifiants d'employé et d'entreprise dans le même espace d'identification, par exemple. leur identifiant est maîtrisé dans une sorte de table Contact, puis company.Id et employee.Id ont tous deux un FK faisant référence à Contact.Id. Je ne pense pas que cette solution soit très bonne puisque Contact est un type super boiteux de ces autres tables.
3. avoir une table de contact comme (ContactId, EmployeeId, CompanyId). Lorsqu'un courrier est créé avec EmployeeId = X, vous recherchez une ligne de contact avec EmployeeId = X. S'il n'en existe pas, vous le créez et utilisez le nouveau ContactId. Idem pour Companyid. Cela vous permet également d’utiliser davantage d’identifiants à l’avenir.