Структурирование внутренней почтовой системы

Question

В моей базе данных две таблицы:

• Таблица компании (ID, CompanyName, CompanyUsername, CompanyPassword)
• Таблица сотрудников (ID, CompanyID, Имя, Имя пользователя, Пароль)

Сейчас я разрабатываю внутреннюю почтовую систему, в которой сотрудники могут писать друг другу, а также напрямую в корпоративную учетную запись.

В моей внутренней почтовой таблице есть следующие поля:

• ID
• FromID
• ToID
• Сообщение
• ...

Теперь моя проблема возникает, когда я заполняю таблицу сообщений с идентификаторами (From / To), я понятия не имею, является ли сообщение от компании или сотрудника, поскольку идентификатор может существовать в обеих таблицах.

Каким может быть мое решение?

Обновление

Пример выше был для упрощения моего вопроса.

Таблицы сотрудников и компаний содержат не имя пользователя и пароль, а ссылку на членство в ASP.NET uniqueidentifier для управления входами в систему. Как предложено ниже с использованием пользовательских интерфейсов для управления отправителем и получателем, я использую пользовательский интерфейс контроллера ASP.NET. Благодарю. : -)

Answer 1

Используйте уникальный идентификатор для идентификатора в таблицах Company и Employee и используйте newid () в качестве значения по умолчанию.

Либо объедините таблицы и добавьте поле, чтобы показать, является ли запись Компанией или Сотрудником.

Answer 2

Таким образом, email.ToID может относиться к employee.ID или company.ID, верно? Вы не можете декларативно ограничить этот email.ToID должен существовать хотя бы в одном из (employee.ID или company.ID). Несколько решений:

1. Имеют идентификаторы в таблице электронной почты (ToEmployeeId, ToCompanyId) и проверочное ограничение, ограничивающее, что только один из них может быть указан в данном письме.
2. У идентификаторов сотрудников и компаний в одном и том же пространстве, например их идентификатор идентифицируется в некоторой таблице контактов, а затем в company.Id и employee.Id есть FK, ссылающийся на Contact.Id. Я не думаю, что это решение очень хорошее, так как Contact - довольно слабый супертип этих других таблиц.
3. иметь таблицу контактов, например (ContactId, EmployeeId, CompanyId). Когда письмо раскручивается до EmployeeId = X, вы ищете строку Контакт с EmployeeId = X. Если он не существует, вы создаете его и используете новый ContactId. То же самое касается Companyid. Это позволяет расширять использование других наборов идентификаторов в будущем

Answer 3

Вы можете использовать два внешних ключа для компании и один для сотрудника и убедиться, что установлен только один ключ.