Здравствуйте. Решаю фундаментальную задачу по проектированию. Есть социальная сеть, где можно оставлять комментарии в очень многих местах (стены пользователей, стены групп, фотографии, топики, новости и т.п.) Комментарии по сути схожи в своем принципе работы - имеют схожие атрибуты (дата создания, автор, заголовок, текст, в каком-то случае parent_id для иерархии) и привязываются к соответствующим сущностям. Вопрос же заключается в следующем. Имеет ли смысл создавать нормальные комментарии и иметь простой доступ по одному FK (article_id, news_id, photo_id, ...), тем самым плодить тучу однотипных таблиц и усложнять себе жизнь, или же проще хранить все в одной таблице, осуществляя доступ через type и item_id? К примеру:

Сущность comment :
полетипописаниеidint(11) pkitem_idint (11), fkid записи для связи comment-сущностьtypetinyintтип сущности. К примеру, 1 - article, 2 - news, 3 - phototitlechar(100) заголовок комментарияtexttextтекст комментария

Очевидно, что такое будет гораздо проще хранить, если будет очень много разных типов (а типов будет штук 10 точно) Сюда же можно запихать тикеты, личные сообщения пользователей и т.п.

Берем все комментарии к article с id 10.

Но основной вопрос заключается в том, рационально ли будет иметь такую структуру, если, скажем, комментариев для article будет 10 000 000, а комментариев к news - 10? Таким образом, чтобы взять комментарии для news, нужно будет перелопачивать 10млн записей. Или же проблем быть вообще не должно с правильно проставленными индексами?

Использую MySQL.

Спасибо.

Если делать универсально, то скорее всего будут тормоза. Поэтому думаю над следующей схемой. К примеру, есть юзер, у него есть альбом, у альбома есть комментарий. Но называть таблицы будет сложно:

user
user_album
user_album_photo
user_album_photo_comment

подумал над тем, что можно сделать какие-нибудь алиасы. К примеру:

user // имя сущности
-id // PK

u_album //имя сущности с алиасом родителя
- user_id //FK user

ua_photo
- user_id
- album_id

uap_comment
- user_id
- album_id
- photo_id

Что думаете? И выборки можно будет делать удобно и FK назначать (с единой таблицей, как я понимаю, FK не назначить)

Посмеялся.
Я тут не ради вашего заумного комментария распинался, а спросил совета.

Нормальный вопрос. Или мы тут пасть ниц? Когда буду жениться, приглашу SERG1257 тамадой - он не пропадет. А здесь я описал конкретную проблему, с которой столкнулся и хотел узнать, как ее решают другие люди. Я спросил, как лучше делать, хранить комментарии в одной таблице или в разных, а мне про тут про говно и повидло...