Добрый день!
В данный момент у меня есть необходимость реализовать проект, и в ходе проектирования схемы базы данных (планировал использовать PostgreSQL) у меня возникли сомнения концептуального характера.
Если не вдаваться в глубокие подробности. Есть часть проекта, задача которой - обеспечить хранение файлов разных типов и их метаданных. У файлов есть общие метаданные, актуальные для всех типов файлов (размер файла, имя файла, дата создания, дата изменения, тип файла и т.д.). Помимо этого, у каждого из типов есть свои виды метаданных, например у DOC-файлов это могут быть автор, дата печати, автор последнего сохранения, у JPG-файлов - разрешение, размер, сжатие и т.д.
Заранее неизвестно на 100% точный спектр форматов, метаданные по которым необходимо собирать. В дальнейшем, на основании собранной коллекции метаданных необходимо производить анализ, возможно, некую кластеризацию.
Вопрос, собственно, в том, какая схема БД для такого случая подходит больше всего, с какими сложностями я столкнусь в дальнейшем при выборе той или иной схемы?.
Во время поиска решения я остановился на следующих вариантах:
1. Создание одной большой таблицы для всех файлов, в которой для каждого атрибута файла (размер, автор, разрешение) независимо от типа файла будет иметься отдельный столбец. Проблемы, которые я вижу: запутанная структура таблицы, множество пустых ячеек, добавление столбцов при добавлении нового типа файла.
2. Использование отношение один-к-одному. Грубо говоря, есть таблица file и есть таблицы doc_file, pdf_file, jpg_file и т.д. для каждого типа файла. В таблицу file будет помещаться мета-информация общего вида обо всех файлах без исключения, а в таблицу file только мета-информация файлов конкретного типа. Соответственно id в таблицах file будут являться внешними ключами и ссылаться на id в таблице file. Проблемы: на каждый новый тип файла нужна новая таблица, при запросах придется обращаться как к таблице file, так и к таблице _file.
3. Использование наследования таблиц. Ситуация схожа с предыдущим вариантом. Правда я не знаю, как это будет устроено внутри СУБД: будут ли это аналогично п. 2 или же в каждой дочерней таблице будут столбцы из родительской. При таком подходе частично отпадает проблема использования запросов сразу к нескольким таблицам (или по крайней мере прячется внутри БД).
4. Применение столбцов JSON (для PostgreSQL скорее JSONB). Все индивидуальные для форматов метаданные будут хранится в столбце типа JSON. Насколько это может усложнить общую схему, а ткже сказаться на производительности? Это самый привлекательный и одновременно самый спорный для меня подход.
5. Забить на реляционные БД, быть модным и сделать все на RIAK, или на MongoDB, или на другом NoSQL.
Подскажите, пожалуйста, какой из этих подходов является более верным для описанной выше ситуации. Если однозначного ответа нет, то подскажите, какие плюсы и минусы в разрезе данной проблемы могут возникнуть у каждого из подходов. Хотелось бы на начальном этапе сделать минимум ошибок в проектировании и набраться положительного опыта (а не шишек на лбу, что тоже безусловно опыт, но менее предпочтительный).
Заранее спасибо!
