Рационально ли использовать для получения статистики такую схему:
валить всю инфу по каждому хиту в таблицу лог (и так по каждому ресурсу),
а потом ее разбирать роботами или лучше сразу раскладывать по полочкам.
Нерационально. Для нормального счетчика MySQL - слишком медленное решение. Работать это не будет.




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




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




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


Это во первых, а во вторых при помощи ПХП нельзя на одной
странице поставить кук и тут же его проверить, он появится только после перезагрузки страницы.
Никакого PHP в качестве движка быть не может. Пользовательская часть - да, ради бога. Сам счетчик должен быть написан в виде С проложения быстрого HTTP сервера (0W-httpd) или типа такого.


P.S. Господа форумчане! Чтобы не спорить по пустому, просто стукнитесь в аську 727977; я расскажу где я работаю и чем занимаюсь -- это избавит от необходимости доказывать что и как надо делать для счетчиков.