Столкнулся с дилеммой о хранении комментариев к различным объектам БД. Моделирую ситуацию: существуют следующие объекты: игры, посты пользователей, книги, статьи. У каждого из этих объектов существует возможность комментирования. При этом так же есть, например, профиль пользователя, в котором можно посмотреть все его комментарии (ко всем вышеперечисленным объектам). Предполагаю, что в реальных проектах подобные базы могут достигать сумасшедших масштабов, особенно если хранить все комментарии в одной таблице, поэтому возник резонный вопрос: как правильно организовать хранение комментариев в таком случае? Всё хранить в одной таблице, тогда будет удобнее выбирать данные для отображения, но таблица будет расти в 5 раз быстрее или распределить это по таблицам типа: games_comments, books_comments и т.д., а для отображения всех комментариев пользователя просто пробегаться по всем этим таблицам и собирать записи?
Я предполагал, что на крупных проектах всё же прибегают к возможности уменьшать размер общей таблицы, по сути ведь разбиение таблицы делит общую таблицу на меньшие по условию и для mysql это, по логике вещей, отдельные таблицы, т.е. приходится проверять доп. условие, чтобы понять с какой таблицей работать, разве нет? Или затраты по скорости столь минимальны, что их брать в учёт не стоит?
Lamer1, уменьшать размер общей таблицы можно просто - не хранить в ней данные. если вы таки собираетесь хранить в ней данные - то уменьшить то как? Ну можете какие данные не писать. Иначе никак.
при выборке по ключу партиционирования - бд сама решит что можно не по всем партициям смотреть. а без ключа будет сама лазить по всем партициям. Explain будет показывать какие партиции пришлось посмотреть.
Правильно все однородные данные хранить в одной таблице.
Связи в БД строятся на основании содержимого таблиц, а не на основании их имён.
Иначе потом приходится "бегать по всем этим таблицам и собирать записи".
Так же при проектировании БД следует опираться на требования архитектуры, а не на влажные эротические мечты про "сумасшедшие масштабы". Если когда-нибудь проект достигнет сумасшедших масштабов, то к этому моменту вся архитектура будет переделана не один раз. И проблема комментариев будет решаться в зависимости от реальных проблем с которыми столкнётся проект, а не в соответствии с фантазиями, которые были у кого-то на начальном этапе.
Простой
