Форум MySQL

Продолжение темы:
http://softtime.ru/forum/read.php?id_forum=2&id_theme=5297&page=1

Посмотрел статистику своих запросов и понял, что надо их причесывать:
1. привести все к одному регистру
2. убрать все дополнительные символы (кавычки, скобки, плюсы, запятые, тире... вроде других пока не встречал)
3. Убрать двойные пробелы.
4. Убрать пробелы в начале и в конце.

Из всего перечисленного, я могу сделать пункт 4 и, возможно, 1 (если это актуально).
Пункт 2 и 3 я тоже могу сделать, но такими методами, которые лучше не разглашать, дабы не позориться:)
Нид хелп и все такое:)

1. Это не актуально, так как MySQL сравнивает строки без учёта регистра - только время на этом потеряем, кроме того в PHP часто заморочки с преобразованием регистра в русском.
2. Заменим их на пробелы

<?php   $symbols = array("\"", "'", "(", ")", "+", ",", "-");   $text = str_replace($symbols, " ", $text); ?>

Лучше здесь без регулярных выражений обойтись, так как быстрее
3. Тут уже удобнее регулярными выражениями сработать

<?php   $text = trim($text);   $text = preg_replace('|[\s]+|',' ',$text); ?>

<?php    $text = preg_replace('|[\s]+|',' ',$text);  ?>

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

Все, причём не только пробелы, но и невидимые символы, перводы сторок, признак конца файла и пр. если вдруг просочатся :)))

рабочий вариант есть. Можно приступать к тестированию. Файл count.php трудится у меня уже целый день - пока рецидива не замечено (правда, регулярные выражения добавил только вечером, но их опробовал на другом скрипте).
Отчет пожно и усложнить, но я пока не придумал для чего. Придумаю - может и займусь:)

Начну с завтрашнего дня модернизировать наш счётчик...

Cheops, а что по поводу аккумуляции старых записей? Как это планируется реализовать?

Завести таблицу, с кучей полей под каждый из замеряемых параметров - одна строка - один месяц и такую же таблицу для аккумуляции под недели, чтобы была месячная, недельная статистика и суточная за последний месяц.

То есть, как я понимаю, показатели не будут рассчитываться на лету вообще, а будут только подцепляться из этой таблицы?

Нет будут, в пределах интервала от текущего дня до 30 дней назад, а при вычислении статистики за всё время к этим 30 дням будут приплюсовываться значения из аккумуляторов. При этом аккумуляторы будут позволять просматривать понедельную и помесячную статистику.

Тогда не вполне понятен такой вопрос: месяц у нас не календарный, а рассчитывается от текущей даты. То есть если позавчера мы скинули в аккумулирующую таблицу данные, то как завтра будут рассчитываться показатели "за неделю" и "за месяц"?
Или мы переходим к календарным периодам?

Я тоже думал... наверное придётся плавающую точку оставить, т.е. один месяц должен быть строго динамичный, а аккумулировать данные по календарным месяцам, таким образом как накапливается полный календарный месяц + 30 дней - сбрасываем каледндарный месяц в статистику... т.е. динамическая граница будет плавать от 1 месяца до 2-х... правда многоэтажно и сложнова-то получается.

Да нет, это самое логичное решение. Только, не вижу смысла привязываться к календарным месяцам: просто с момента пуска счетчика держим 2 месяца оперативных, а как только количесво дней превышает 2 месяца, один месяц скидываем в архив.

Предположим, счетчик запущен 15 числа. То есть спастя 2 недели, мы должны считать их целым месяцем?
С другой стороны, календарные месяцы удобнее сравнивать...

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

А каких показателей это будет касаться?
Хосты
Засчитанные хосты
Хиты
Операционные системы
Броузеры
Поисковые роботы

А вот все остальное не очень понятно как в эти таблицы засунуть...

Я вот чего подумал, а зачем нам две таблицы searchquerys и refferer - может сделаем одну - если это поисковик, то внём будут сразу ключевые слова, если это просто реферер - его так реферером и оставлять, а различать где есть что можно по полю searches?

а в чем экономия? в Таблице refferers, например, поля searches теперь нет (оно, конечно, небольшое, но сам факт)... можно также оттуда убрать поле ip (все равно нигде не используется). А можно пойти и другим путем: чтобы поле типа enum создавалось на основании таблицы links. Экономия будет офигенная:) Но при этом мы потеряем возможность посмотреть откуда конкретно пришел посетитель, а я от этого не откажусь!:)

Кроме того, таблица searchquerys имеет поле query типа tinytext, в то время как name.refferer - text.