Я разрабатываю систему управления документами для моего дипломного проекта.
В этом проекте пользователи добавляют метаданные документов в мою таблицу «документы» в реляционной базе данных.
И, конечно же, существуют различные виды документов, такие как письма, счета и т. Д. Поэтому они имеют различный набор атрибутов для каждого типа документа. (и, конечно, некоторые общие атрибуты, такие как «автор».)
И пользователи могут определять новые типы документов с новым набором атрибутов (или они могут использовать существующие атрибуты, которые ранее были определены пользователями). И, конечно, пользователи могут добавлять или удалять атрибуты после вставки десятков документов.
Вопрос в том, как мне хранить такие данные в моей системе реляционных баз данных? (Postgres в этом случае.)
Я проводил некоторые исследования, нашел некоторые решения, но не могу решить, что делать.
Должен ли я иметь базовую таблицу документов, и для каждого вновь добавленного атрибута я должен создать отдельную таблицу (docID, значение) и затем присоединиться к ним по запросу пользователей?
Или я должен создать новую таблицу для каждого типа документа с определенными атрибутами? а затем объединить их по запросу пользователей?
Или я должен создать сравнительно большую таблицу, скажем, 200 дюймов, 200 вариантов, 200 дат, 200 чисел с плавающей запятой и т. Д., И они сопоставляют определения с этими столбцами для каждого типа документа.
В качестве начального требования,
пользователь должен иметь возможность заказывать, фильтровать (искать) документы, чтобы получать какие-либо отчеты по ним любым способом.
И эти документы и их атрибуты будут иметь права доступа, я имею в виду, что они будут иметь отношения с другими таблицами в моей базе данных.
Мое главное соображение здесь не в легкости разработки. Производительность и функциональные требования являются наиболее важными.
Потому что в моей демонстрации у меня должна быть база данных, в которую уже вставлено не менее 1 миллиона документов.
Я могу предоставить больше информации, если потребуется.
Спасибо.