>Касательно же сабжа, то здесь гораздо важнее правильно
>организовать структуру БД и таблиц.
Всеми руками-ногами присоединяюсь.>Еще раз возвращаясь к структуре таблицы primary key(month,day,time) все же выбран неудачно,
>так как нагрузка у автора явно маленькая и письма ходят редко,
> то ему оно подойдет, а вот на больших объемах нет
>- так как очень часто primary key будет повторятся, соответственно в
>базу данные попадать не будут (дублирование primary невозможно по определению).
>ТО есть, Женя, Мысль у тебя хорошая. И даже нужная. Только еще
>сырая. Я сам такую гадость сейчас пишу. Только я пишу не
>единичную, а суммарную для нескольких серваков. Потому так и разжевываю, что
>и зачем. Касательно предыдущих ораторов, того же Сергея, могу сказать, что
>скорее всего статистику они генерят один раз и забывают об этом.
Конечно, почти так. Точнее, интересующую меня статистику можно получать другим путем. Так, собрать данные о размерах писем проще в контент фильтре, если он это умеет, а если не умеет, но умеет со внешними модулями работать - то написать такой модуль. На эту тему можно долго говорить, но это будет все же немного офтоп.
>Для меня такая проблема встала, когда пришлось частенько парсить логи нескольких почтовиков,
>при чем у каждого он разросся от полутора до 2-х с
>половиной гигов. И просто статистика типа сколько от и до пользователя
>прошло писем мне была не нужна. Мне нужны были данные, как
>прошло конкретное письмо в конкретном интервале времени,возможность вернуть лог полностью и
>касательно одного письма, и т.д.
Ага, вот это как "прямое" назначение логов :))) я рад просто, что у меня они не по 2 гига, и что это требуется не особо часто, иначе пришлось бы так же, как и Вы поступать. А так можно особо не напрягаясь скриптами управится.
>А это уже слишком специфичные задачи и большинству они нафиг не нужны.
Золотые слова. На задачу же и решалка :)
