Может, я что-то пропустил, но поиском не нашел.
Вопрос простой — где можно почитать о структуре БД?
Конкретное назначение таблиц, полей и связи между сущностями.
Думаю, это будет интересно всем, так как менять все равно приходится руками в базе. И в wiki этот раздел хорошо бы добавить.
Тружусь над мед.сообществом, модель сайта вынуждает переделывать структуру. Сам ничего толкового придумать не смог, зато взял бывшую модель кадабры, а именно:
Все блоги разделены на 2 категории: общие и тематические. ОБщие — это что угодно (фристайл), не связанное с узкой тематикой сайта. Тематические блоги — привязанные к подкатегориям.
При создании блога указываем, к какой категории он относится. В случае выбора «тематический» получаем выпадающий список с подкатегориями. Называем блог, описание, создать — получаем блог, привязанный к подкатегории.
Мне это нужно для того, чтобы доктора могли находить блоги только из тех областей медицины, которые их интересуют, а не искать по названиям блогов, которые не всегда точно отображают то, что в них опубликовано :)
Вопрос: это возможно сделать в livestreet? Очень надо, может кто поможет, отблагодарю как следует =)
Такая проблема. Есть дизайн, я его сверстал, а вот куда пихать — не могу понять. Засунул в header.tpl. А где код, отвечающий за вывод контента? В какой файл нужно перенести часть моей таблицы? Воообще ничего не ясно, очень прошу объяснить структуру шаблона.
Для теста производительности движка импортировал базу данных [4092 юзера, 4113 блогов (включая личные), 4845 топиков, 27231 комментириев] с работающего сайта из другого движка.
По данным du -hc /каталог/базы данных, размер базы, включая индексы, составляет 53 МБайта в бинарном виде.
При входе на сайт при первом запросе каких-либо данных (например каждой следующей страницы топиков) включаются тормоза. Очень сильные, достигающие 1мин, до тех пор, пока данные не достанутся из базы и поместятся в кеш.
Факт, что узким местом являются запросы к базе подтверждается и блоком статистики внизу страницы и менеджером процессов top (ОС Debian Linux 4.0).
Использование memcached вместо файлового хранилища ускоряет загрузку, но уже после выполнения запросов и при повторных обращениях, когда роль БД минимальна.
При беглом анализе структуры таблицы топиков, видна ее частичная неоптимальность, как например хранение текста топика в 3х экземплярах (тизер, полный текст и оригинал до обработки парсером-типографом).
Есть у уважаемого сообщества какие-либо идеи по поводу узкого места в работе с БД и/или предложения по нейтрализации сего узного места?
Отдельно хочу поинтересоваться у автора о причинах такого неоптимального хранения текста топиков?
