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

Question

У меня есть две таблицы в моей базе данных:

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

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

Моя внутренняя почтовая таблица содержит следующие поля:

• ID
• ФромИД
• ТоИД
• Сообщение
• ...

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

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

Обновить

Приведенный выше пример был призван упростить мой вопрос.

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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