Это хорошая практика проектирования баз данных для отслеживания документов? - PullRequest
Новая
       41

Это хорошая практика проектирования баз данных для отслеживания документов?

0 голосов
/ 22 мая 2019

Я пытаюсь создать базу данных для отслеживания документов. Каждый документ может иметь несколько версий, и каждая версия имеет ряд свойств, связанных с ним. Тем не менее, каждая версия может быть связана с несколькими категориями. Единственное общее свойство между версиями - это имя документа.

Мой текущий дизайн

Таблица документов:

  • id (первичный ключ)
  • имя

Таблица DocumentVersions

  • id (первичный ключ)
  • document_id (внешний ключ)
  • описание
  • revision_reason
  • и т.д ...
  • 1026 * Отметка времени *

Таблица DocumentCategories

  • id (первичный ключ)
  • имя

DocumentVersionsDocumentCategories Таблица

  • document_version_id
  • document_category_id
  • (вместе они составляют первичный ключ)

Мне было интересно, выглядит ли эта структура хорошо? Кроме того, что будет в случае использования таблицы присоединения DocumentVersionsDocumentCategories по сравнению с таблицей DocumentCategoriesTable с полями: id, document_version_id, name? А также будет ли какая-либо причина иметь поле метки времени в Таблице документов?

API должен будет иметь возможность поиска, фильтрации и разбивки на страницы документов, показывая все категории для каждого документа и отметку времени последней версии. т.е. возвращает массив документов, таких как: 

[{ name: "first doc", categories: "first category, second category", timestamp: 01/01/2019 }, 
{ name: "second doc", categories: "second category", timestamp: "01/01/2020 }, 
{ name: "third doc", categories: "fourth category", timestamp: 01/01/2019 }]

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

...