есть различные медиа: фото, видео, аудио. Каждый из них имеет разный набор атрибутов. Фото: ссылка на источник, размер. Видео: название видео, ссылка на источник, размеры, продолжительность и ссылка на preview. Аудио: ссылка на источник, продолжительность, исполнитель, альбом.
Как видно, поля у этих сущностей разные, так что объединить всё в одну таблицу будет весьма непродуктивным занятием. Я прочитал в интернете, как можно справиться с этой проблемой.
Создаётся enum со всеми возможными типами данных. Создаётся основная таблица, в которой будет храниться идентификатор и тип сущности (фото, видео, аудио). Далее создаются таблицы, где будут храниться непосредственно фото, видео, аудио . В этих таблицах также есть идентификатор, который совпадает с идентификатором основной таблицы.
Чтобы достать данные* достаточно сделать JOIN по нескольким таблицам. У меня вопрос: если будет очень много данных, то не будет ли "JOIN нескольким таблицам" являться узким горлышком? Я понимаю, что в моём случае было бы лучше хранить данные в NoSQL базе данных, но, к сожалению, такой возможности нет.
* - вообще помимо тех перечисленных полей в таблице ещё есть идентификатор сообщения, к которому привязаны все эти аудио, видео и фото. Банальный use-case: достать N последний сообщений с соответствующими им медиа, если есть.
Jsonb
Что с этими данными нужно будет делать? Просто отдавать или же обрабатывать?
Хм, ну так-то да, я что-то не подумал. Ведь сами по себе метаданные (продолжительность, имя исполнителя, имя альбома...) никак не будут агрегироваться. Их надо лишь сохранять (от стороннего сервиса), и отдавать конечному пользователю.
>то не будет ли "JOIN нескольким таблицам" являться узким горлышком? Не особенно. Что важно -- что вероятнее всего -- попытка впихнуть это в json или как-то ещё в один тапл окажэтся ещё более узким горлышком. Хотя, в любом случае, ключевой проблемой наверняка окажэтся вообще не это.
Ну, ради простоты пока все метаданные помещу в jsonb. Всё равно мне их не надо анализировать
Обсуждают сегодня