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

Question

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

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

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

Решение 1:

Фирменный стол

• CompanyID

Таблица отделов

• DeptId

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

• EmployeeID

Таблица атрибутов типа

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

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

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

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

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

Решение 2:

Фирменный стол

• CompanyID

Таблица отделов

• DeptId

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

• EmployeeID

CompanyAttachments table

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

таблица DeptAttachments

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

Таблица EmployeeAttachments

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

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

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

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

---

Редактировать 1:

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

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

Фирменный стол

• CompanyID

Таблица отделов

• DeptId

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

• EmployeeID

Вложения

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

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

Я бы выбрал вариант 2.

Примерно так:

альтернативный текст http://img84.imageshack.us/img84/815/dbso.png

Answer 5

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

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

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