Protossan: Ну почему, можно сделать и запрос с плавающим окном
SELECT *
FROM (
SELECT `p1`.`usrid` AS `usrid`, COUNT(*) AS `cnt`,
`p1`.`data` AS `data`
FROM `posts` AS `p1`
JOIN `posts` AS `p2` ON `p1`.`usrid` = `p2`.`usrid`
AND `p2`.`data` BETWEEN `p1`.`data`
AND `p1`.`data`+INTERVAL 1 HOUR
GROUP BY `p1`.`postid`
ORDER BY `cnt` DESC
LIMIT 10
) AS `t1`
JOIN `posts` AS `t2` ON `t1`.`usrid` = `t2`.`usrid`
AND `t2`.`data` BETWEEN `t1`.`data`
AND `t1`.`data`+INTERVAL 1 HOUR
ORDER BY `t1`.`cnt`, `t1`.`usrid`, `t2`.`data`
Но тут есть неприятность. Если, скажем, окно в 1 час, а кто-то два часа постил раз в минуту, то получится, что с 00:00 по 01:00 у него 60 постов, с 00:01 по 01:01 60 постов,... с 00:59 по 01:59 - тоже 60 постов.
Sunsh1ne: Можно через CONCAT и GROUP_CONCAT, но потом могут быть сложности с обратным разделением, в статье могут быть и запятые, и скобки и кавычки...
Добавлю, что эти байты не только хранятся, но ещё и в больших количествах передаются из базы в приложения и обратно. Да и на скорость построения индексов, особенно составных, размер и тип данных тоже влияет.
AVKor: "А теперь забудьте то, чему вас учили раньше" - стандартное начало любого курса в институте.
За пределами школьной математики существуют многозначные функции. Такая функция для каждого элемента первого множества ставит в соответствие некоторое подмножество элементов второго множества, причём как минимум одно из этих подмножеств состоит более, чем из одного элемента.
Rou1997: Работа со строками там - это разве что сравнение в лексере, и то можно заменить на посимвольный конечный автомат. Ну ещё работа со строковыми константами в оптимизаторе, но это тоже мелочи.
Rou1997: Зачем готовый, по грамматике языка строится лексер, синтаксический анализатор (парсер), семантический анализатор, генератор и оптимизатор кода. Посмотрите, например, классику - книгу красного дракона.
Ну, операции со строками компилятору нужны по минимуму, так же, как и регулярки. И то и другое успешно заменяется гораздо более мощными конечными автоматами и парсерами.
Макс: Точное время посчитать невозможно, поскольку хэш может совпасть на первой же строке, а может не совпасть и на первых 2128 строках. Если известен набор символов пароля и его максимальная длина, то можно оценить максимальное время полного перебора, {размер_алфавита}{длина_пароля}/{скорость_перебора}.
Но тут есть неприятность. Если, скажем, окно в 1 час, а кто-то два часа постил раз в минуту, то получится, что с 00:00 по 01:00 у него 60 постов, с 00:01 по 01:01 60 постов,... с 00:59 по 01:59 - тоже 60 постов.