FreshTopics (mod "показать 100 свежих тем")

[iks]

На ORDER BY конечно заменил.

Насчет DDOS атаки в какой-то мере согласен с тобой, Xpert
(правда, все атакующие, не надо забывать, должны являться залогинившимися, т.е. членами форума)

Но насчет 60 дней - не совсем.

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

Подскажите, как ограничить размер вот такой выборки сотней экземпляров?

Код: Выделить всё

$sql = "SELECT post_id 
FROM " . POSTS_TABLE . " 
ORDER BY post_time";

[crash]

ну в конце запроса наверное указать LIMIT 100

[iks]

crash, спасибо, код

• $sql = "SELECT post_id
  FROM " . POSTS_TABLE . "
  ORDER BY post_time
  LIMIT 100";

заработал!

Но! Он выдает ПЕРВЫХ 100 тем. А как сделать, чтобы 100 последних? Как сделать desc сразу в выборке?

[VVVas]

ORDER BY post_time DESC

[iks]

VVVas, спасибо!

по резульатам коллективных заявок/трудов вышла версия 1.0.1 8)

1й пост обновлен

[VVVas]

iks
Лучше сделайте за 60 дней, так лучше будет.

Добавлено спустя 24 секунды:

Ну мне так будет больше нравиться.

[iks]

дело в том, что на некоторых форумах (например, ixbt или onliner.by) за 60 дней сообщений не просто много, а очень много. Поэтому для означенных целей вполне годится 100 (можно самому поменять на 1000 или другое число) сообщений.

[Xpert]

Не post_time, a post_id, это более быстрый индекс.

[iks]

Xpert, AFAIR в SQL для индексов понятие "быстрота" не используется в сравнительной степени для одной и той же таблицы: либо индекс есть либо его нет.

[Xpert]

Однако, первичный и более короткий индекс всегда является более быстрым.

[iks]

Однако, первичный и более короткий индекс всегда является более быстрым.

данное выражение не имеет ничего общего с действительностью, поверь моему 15-летнему опыту работы с реляционными базами данных 8)

интересен ход твоих мысленй - за счет чего он должен быть быстрым-то?

первичность индекса никак не влияет на скорость выборки по нему
свойство первичности лишь говорит о том, что такой индекс однозначно определяет порядок следования записей в БД

скорость выборки из sql-базы ровным счетом никак не зависит от количества сегментов в индексе или их типу!
операцией присваивания (заполнения индексного шаблона) в таких случаях пренебрегают, т.к. она занимает ничтожное время по сравнению с временем осуществления самой выборки, соответственно, сколько сегментов и какова их длина - 1 байт или 25 дат - на практике не имеет ровным счетом никакого значения.

[Xpert]

Она зависит в первую очередь от типа поля. Все остальное это уже не особенности БД, а общие вопросы оптимизации любого ПО. Тут минус одна операция, там минус одна - и вот их уже две. Совсем не зря в том же viewforum.php в качестве параметра упорядочивания используется post_id, а не post_time.

[iks]

насчет типа - читай последний абзац, могу лишь повторить, что разница настолько мала и ничтожна по сравнению с временем выборки из БД, что ею в таких случаях всегда пренебрегают
(даже если сделаешь сотни тысяч присваиваний, разница будет составлять доли секунды, если вообще будет заметна - легко проверить, между прочим )

могу согласиться лишь с тем, что при сортировке по post_id действительно всегда будет один и тот же порядок, в моем же случае - если 2 поста были размещены в одинаковое время (с точностью до секунды), то недетерминировано, в каком порядке (и одинаковом ли) они выведутся на экран при нескольких одинаковых запросах

8)

[Xpert]

Действительно, упустили главное, post_time - не уникальный ключ

[Палыч]

А зачем вообще использовать post_time..? Если не организуется (через input например) условие выборки: за последние....дней?
Достаточно, по-моему, post_id.