Ровно наоборот. Коммент - это вырожденный и подчинённый пост. Иначе замучаетесь логически переворачивать при проектировании и разработке.


В реальности посты первичны, а комменты подчинены и вторичны. Точно так же надо рассматривать и обобщения этих сущностей.

Как уже написано выше, она таблица/тип объекта для постов и комментов.

И одна таблица для лайков. При чём любых лайков. Потому что лайк это лайк. Куда бы он не прилагался.

Если лайки будут прилагаться к разным типам сущностей, то вводите центральную таблицу сущностей (объектов). Это в будущем поможет, система будет связной. Сквозное ID по всей системе весьма удобно во многих случаях. Только не нужно центральный идентификатор делать гуидом, если есть возможность этого избежать.

Я бы сделал иначе:

Корневая таблица Сообщения (Message), в которой лежат сообщения всех типов (включая форумы, как сообщения первого уровня, нулевой уровень - это сайт). Там самая базовая инфа, служащая исключительно для опознания сущностей, их связи (и генерации и хранения сквозного ID).

К ней уже создаются добавочные таблицы для хранения дополнительных технических атрибутов, а так же собссно содержания. Вида MessageSubj и MessageLikes.

В таблице сообщений создаём поле TypeID, ссылающееся на таблицу типов сообщений. Тип smallint или даже tinyint для экономии места и убыстрения чтения. Топики-посты значит у нас будут иметь тип сообщения = 3 (0 сайт, 1 форум, 2 прикреплённая тема). Комменты соответственно 4.

А чтобы ничего не тормозило, создаём фильтрованный индекс с условием (TypeID = 3) и матвьюху, смотрящую на него.


Для чего это всё делается именно так? Для единообразия и простоты кода. Который будет со временем усложняться и наворачиваться. Например управление правами куда как проще будет делать для одной таблицы, чем для многих разных (ну если делать в разных, то получим иерархию вложенности форум-топик-коммент-лайк, отдельно "личное сообщение" и т.п. и это только навскидку).