-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
PHPBB хранит посты в двух отдельных таблицах. Почему?
- Автор темы Krishna
- Дата начала
Vladson
Сильнобухер
Krishna
Ну там не JOIN а просто выборка из нескольких таблиц (разработчики рнрВВ вообще недолюбливают JOIN) а смысл всей каши давольно прост, по их мнению текст сообщения это лишь часть необходимая для просмотра топика, в то время как расчёты всего остального (с участием uid, ptime но без текста) встречаются часто
Вообще я тоже не считаю что в рнрВВ идеальная структура, однако всё-же по сравнению со многими другими форумами рнрВВ работает немного быстрее... (конечно часто в ущерб функциональности)
Ну там не JOIN а просто выборка из нескольких таблиц (разработчики рнрВВ вообще недолюбливают JOIN) а смысл всей каши давольно прост, по их мнению текст сообщения это лишь часть необходимая для просмотра топика, в то время как расчёты всего остального (с участием uid, ptime но без текста) встречаются часто
Вообще я тоже не считаю что в рнрВВ идеальная структура, однако всё-же по сравнению со многими другими форумами рнрВВ работает немного быстрее... (конечно часто в ущерб функциональности)
Krishna
Продался Java
Vladson
kruglov
[sql]
CREATE TABLE phpbb_posts (
post_id mediumint(8) unsigned NOT NULL auto_increment,
topic_id mediumint(8) unsigned NOT NULL default '0',
forum_id smallint(5) unsigned NOT NULL default '0',
poster_id mediumint(8) NOT NULL default '0',
post_time int(11) NOT NULL default '0',
poster_ip varchar(8) NOT NULL default '',
post_username varchar(25) default NULL,
enable_bbcode tinyint(1) NOT NULL default '1',
enable_html tinyint(1) NOT NULL default '0',
enable_smilies tinyint(1) NOT NULL default '1',
enable_sig tinyint(1) NOT NULL default '1',
post_edit_time int(11) default NULL,
post_edit_count smallint(5) unsigned NOT NULL default '0',
PRIMARY KEY (post_id),
KEY forum_id (forum_id),
KEY topic_id (topic_id),
KEY poster_id (poster_id),
KEY post_time (post_time)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251[/sql]
-~{}~ 01.04.06 18:50:
Здесь
poster_ip varchar( 8 ) NOT NULL default '' - понятно что, а
post_username varchar( 25 ) default NULL - имя юзера в случае анонимного поста.
По-этому выгоды по-прежнему не ясны. Может это рудимент?
А разве это не INNER JOIN? 0
Звучит логично, первая мысль была такая же, но при более внимательном рассмотрении выясняется, что на самом деле таблица постов считается как раз в основном во viewtopic, а для остальных экранов (функ-ий) данные кешируются в других таблицах - таблице форумов и топиков. Поправьт меня all, если ошибаюсь.
kruglov
И такая мысль мне пришла в голову. Но, разрабы пхпбб хранят в таблице и поля переменной длины, что делает её динамической размерности.
[sql]
CREATE TABLE phpbb_posts (
post_id mediumint(8) unsigned NOT NULL auto_increment,
topic_id mediumint(8) unsigned NOT NULL default '0',
forum_id smallint(5) unsigned NOT NULL default '0',
poster_id mediumint(8) NOT NULL default '0',
post_time int(11) NOT NULL default '0',
poster_ip varchar(8) NOT NULL default '',
post_username varchar(25) default NULL,
enable_bbcode tinyint(1) NOT NULL default '1',
enable_html tinyint(1) NOT NULL default '0',
enable_smilies tinyint(1) NOT NULL default '1',
enable_sig tinyint(1) NOT NULL default '1',
post_edit_time int(11) default NULL,
post_edit_count smallint(5) unsigned NOT NULL default '0',
PRIMARY KEY (post_id),
KEY forum_id (forum_id),
KEY topic_id (topic_id),
KEY poster_id (poster_id),
KEY post_time (post_time)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251[/sql]
-~{}~ 01.04.06 18:50:
Здесь
poster_ip varchar( 8 ) NOT NULL default '' - понятно что, а
post_username varchar( 25 ) default NULL - имя юзера в случае анонимного поста.
По-этому выгоды по-прежнему не ясны. Может это рудимент?
Rammstein
PHPClub::News
Зачем думать. Просто ребята сели выпить и один из них сказал: "А давайте...". И всё тут Хотя, я должен сказать, что такое применимо только к России.
[offtop]
У нас в области многие не могут понять, почему один из городов растянулся на 50km, при населении в 200'000. Видимо, по вышеуказанному принципу строили.
[/offtop]
Хотя, я должен сказать, что такое применимо только к России.[offtop]
У нас в области многие не могут понять, почему один из городов растянулся на 50km, при населении в 200'000. Видимо, по вышеуказанному принципу строили.
[/offtop]
Не надо нам тут русофобии! Авторы phpBB --- феерические долбо@#ы, в суровом российском климате такие просто не выживают.Автор оригинала: Rammstein
Зачем думать. Просто ребята сели выпить и один из них сказал: "А давайте...". И всё тут
Positive
Новичок
Я тоже задавался этим вопросом. Ответа не нашел, решил проверить экспериментально - слил в одну таблицу.
Стало слегка тормозить, но не факт что именно поэтому, может сам гдето накосячил.
Форум нормльной нагруженности - 100-150 чел одновременно.
Посмотрел-посмотрел, и вернул как было.
Стало слегка тормозить, но не факт что именно поэтому, может сам гдето накосячил.
Форум нормльной нагруженности - 100-150 чел одновременно.
Посмотрел-посмотрел, и вернул как было.
Vladson
Сильнобухер
>>> Авторы phpBB --- феерические долбо@#ы
Если вы считаете что можете лучше то почему мы до сих пор не имеем бесплатного двига форума у которого небыло бы недостатков ?
Хвастаться можно сколько угодно, а авторы рнрВВ не 3.14#здят на всех кого не лень, а просто делают доброе дело и не вы ёживаются (конечно недостатки можно найти, но у кого их нет ?)
Если вы считаете что можете лучше то почему мы до сих пор не имеем бесплатного двига форума у которого небыло бы недостатков ?
Хвастаться можно сколько угодно, а авторы рнрВВ не 3.14#здят на всех кого не лень, а просто делают доброе дело и не вы ёживаются (конечно недостатки можно найти, но у кого их нет ?)
По существу вопроса: в PostgreSQL есть такая фишка как TOAST, поля типа text и т.п., размером больше (примерно) пары килобайт хранятся не в основной таблице, а в дополнительной (пользователю этой разницы не видно).Автор оригинала: Krishna
Sad Spirit:
А что-нибудь по существу вопроса можно?
Так что подход имеет право на существование, другой вопрос, насколько аккуратно аналогичная штука сделана в phpBB?
Человек может написать крутую программу и т.д. и т.п. но при этом всё же быть феерическим долбо@#ом. Я ваще-то автор русского перевода phpBB, и высказываюсь по мотивам (попыток) общения с его создателями...
Vladson
Сильнобухер
А я утверждаю что всё познаётся в сравнении и огромное количество людей которые его используют в тысячи раз больше долбо@#ы (в процентном соотношении их наверное более 90%) но речь в топике в общем не об этом...
Сорри кстати за ламерство, тексты и блобы это понятно, а вот варчары разве не фиксированы ?
(просто не приходилось задаваться таким вопросом)
kruglov
Новичок
Vladson
Варчары не фиксированы. Чары фиксированы.
В phpmyadmin можно посмотреть в структуре таблицы справа. Формат фиксированный или динамический.
Kelkos
>что то мне намекает, что наличие текстовых полей в таблице невлияет на скорость поиска записей
Ну, если вы создадите таблицу с текст-полем, то увидите, что формат у таблицы будет динамический.
Вообще, по опыту могу сказать, что текст-поля поиск замедляют. Особенно мегабайтные.
Варчары не фиксированы. Чары фиксированы.
В phpmyadmin можно посмотреть в структуре таблицы справа. Формат фиксированный или динамический.
Kelkos
>что то мне намекает, что наличие текстовых полей в таблице невлияет на скорость поиска записей
Ну, если вы создадите таблицу с текст-полем, то увидите, что формат у таблицы будет динамический.
Вообще, по опыту могу сказать, что текст-поля поиск замедляют. Особенно мегабайтные.
alexhemp
Новичок
Тут все просто - если размер записи базы фиксирован то по "номеру" записи в таблице легко вычисляется ее смещение в файле. А если нефиксирован - то нужно как миниумум хранить таблицу смещений, что очевидно сказывается на скорости. На маленьких нагрузках будет совершенно незаметно, но на больших могут вылезти отличия.