Лучший способ создать этот сценарий базы данных?

Question

Требование - хранить вложения для разных типов объектов.

Скажем, у нас есть 3 типа организаций: компания, отдел и сотрудник. Каждый может иметь несколько вложений (документов).

Какой лучший способ справиться с этим?

Решение 1:

Стол компании

• Идентификатор компании

Стол отдела

• DeptId

Таблица сотрудников

• EmployeeID

Таблица AttchmentType

• TypeId
• Типы (компания, отдел, сотрудник)

Таблица вложений

• вложения
• TypeId (отображается на тип вложения)
• entityId (отображается на CompanyId / DeptId / EmployeeId)

Плюсы: я могу легко добавлять новые типы объектов в будущем

Минусы: в этом случае я не могу поддерживать отношения внешнего ключа между сущностями и вложениями.

Решение 2:

Стол компании

• Идентификатор компании

Стол отдела

• DeptId

Таблица сотрудников

• EmployeeID

CompanyAttachments table

• вложения
• CompanyId (FK)

Таблица DeptAttachments

• вложения
• DeptId (FK)

Таблица EmployeeAttachments

• вложения
• EmployeeId (FK)

Плюсы: целостность внешнего ключа

Минусы: для добавления новой сущности мне нужно отдельно иметь новую таблицу вложений.

Итак, каков наилучший способ предположить, что в будущем мне может понадобиться добавить новые объекты?

---

Изменить 1:

Спасибо за ваш ответ, ребята.

Если я захочу перейти к решению 2, я увижу, что проще создавать новые столбцы в таблице вложений, а не создавать новые таблицы вложений для каждой сущности, просто чтобы отобразить их? что-то вроде,

Стол компании

• Идентификатор компании

Стол отдела

• DeptId

Таблица сотрудников

• EmployeeID

Вложения

• вложения
• CompanyId (FK)
• EmployeeId (FK)
• DepartmentId (FK)

я что-то здесь упускаю?

Answer 1

Я бы определенно пошел с решением № 2. Ваш один профессионал для решения № 1 на самом деле не профессионал. Если вы добавляете новую сущность, вам обязательно нужно будет добавить новую таблицу для этой сущности, и вы уже добавите или измените существующий код для ее обработки. Вы должны быть в состоянии сделать некоторые общие объекты, которые обрабатывают шаблон, чтобы дублированный код не был проблемой.

Answer 2

Надеюсь, это говорит само за себя.

Answer 3

Я голосую за решение 2, потому что таким образом вы можете обеспечить соблюдение ссылочной целостности надлежащим образом. Кроме того, вы можете легко (при необходимости) добавить поля для специальных вложений (например, EmployeeAttachments может иметь битовое поле "PersonalPicture" или подобное)

Answer 4

Я бы пошел с вариантом 2.

Что-то вроде этого:

http://img84.imageshack.us/img84/815/dbso.png

Answer 5

Другие вещи для рассмотрения:

Собираетесь ли вы свернуть вложения? т.е. вложения сотрудника связаны с его / ее отделом и их компанией? если это частый запрос, то отдельная таблица вложений и отдельная опция таблицы поиска сущностей с большим индексом могут повысить производительность запроса.

Кроме того, будет ли количество вложений большим и / или достаточно большим, чтобы вам пришлось поместить эти таблицы на отдельное устройство или в другую систему хранения (например, указатели файловой системы)? Управление является проблемой, а также производительность.