Какую схему БД выбрать для hashtag'ов всего?

Question

[brainflow]

Есть социальная сеть, там есть разный контент: посты на стене, комментарии, видео(с описанием), фото, сообщения.
Для всех типов контента пользователь может написать #хештег.
При вводе #хештег в поиске должен быть поиск по всем типам контента.

Подскажите, пожалуйста, как это лучше всего организовать на уровне бд(используем postgresql).
Как самое очевидное решение:

• Таблица с контентом
  
• Таблица с тегами
  
• Таблица связи теги с контентом tag_id -> content_id
  
• На фронтенде или бекенде преобразуем #хештег в ссылку
  

Чем не нравится, при добавлении поста в котором будет 50 тегов, придется делать 50 запросов на поиск тегов таблице тегов, потом 50 вставок в таблицу связей, в идеале еще счетчики обновлять, но это можно убрать в фон.

Может подскажите более стройное решение.
На SOF нагуглил только это:
stackoverflow.com/questions/9282091/best-way-to-ma...
stackoverflow.com/questions/48475/database-design-...

Answer 1

[mistergonza]

Я конечно не спец в Postgres, как вариант можно для тегов использовать поле типа json в таблице с контентом.

Comments

[brainflow]

Да, спасибо большое за совет, думал об этом, но получается,
- теряем возможность задать хештегу описание и частотность, как в случае с отдельной табличкой
- непонятно как выводить самые популярные хештеги, фигачить джойн всех контентных страниц или в фоне гонять скрипт,который будет актуализировать счетчики в отдельной таблице.

Интересно было бы послушать примеры из жизни, может кто решал подобное или знает, как это решается в больших соц. сетях.

[brainflow]

Опечатался: всех контентных таблиц* , а не страниц

[mistergonza]

brainflow: Да я тоже когда ответ писал, думал что решение наркоманское. Но при простом листинге постов со списком тегов будет очень быстрым. А вот для статистики по тегам надо будет прикручивать отдельную таблицу с тегами, где поле тег будет помечено уникальным ключом. Тогда статистика типа популярных тегов будет отображаться быстро, но получается что при добавлении поста будет дублироваться информация в две разные таблицы которые друг с другом ни как не связаны, что не очень элегантно. Да и при получении постов с определенным тегом поиск по полю с json будет медленней чем поиск по ключу. И для нового человека который такой код увидит, будет все не очень логично. Это всё палка о двадцати концах какая-то, вам надо понять для начала для каких данным вам критична производительность. Но я бы свой вариант не использовал, я бы оставил стандартный реляционную модель, отделная табличка для постов, отдельная для контента в постах, отдельная табличка для тегов и там всякие мэни ту мэни связи.

А вообще гляньте во всякие опенсурс проэкты типа Wordpress (он вроде даже с постгерсом работать умеет), как там реалезованно.

[brainflow]

Спасибо за совет попробую поковырять opensource.