Подскажиет структуру БД или методологию

[4m@t!c]

Подскажиет структуру БД или методологию

Пишется сервис типа спайлога.
стал вот такая трабла. Есть таблица, в которую пишется, время и, например, IP посетителя.
Так вот, когда нужно сделать выборку по конкретному сайту, и сгрупировать по страницам информацию (сколько раз посещалась каждая страница), то получается грустно по производительности. СУБД Мускул, записей в ней 8 миллионов. Запрос, описанный выше обрабатывается 30-50 секунд. Группируется 80 тысяч записей в 12 строк. Думали для каждого пользователя создать отдельную таблицу... т.е. соклько пользователей, столько и таблиц ,потом думали по времени разделять таблицы. но, что-то не нравятс идеи - кривые какие-то и негибкие.
Есть еще вариант. Создать таблицу, которая содержит результаты подобных групповых запросов. В эту таблицу налету записывать информацию.
Например: есть ИД сайта, равный 5-ти. Есть таблица группированных данных по страницам, сколько раз просматривали, с полями ИД сайта, имя паги, кол-во просмотров. алгоритм занесения инфы в такую таблицу следующий. приходит очередная инфа о посещении страницы и сразу проверяется, если информация о паге есть в таблице, то прибавляем к кол-ву еденцу, если ее нет, то добавлем новую строку.
вопросы:
1. Насколько корректен последний вариант?
2. Если я изобретаю велосипед, то как он выглядит, намекните, пожалуйста?

 

[su1d]

как одно из решений:
создай PRIMARY KEY(site_id, hit_day)
выполняй INSERT с новыми данными.
если mysql_affected_rows() вернёт 0, то это будет означать, что запись уже существует и primary key не позволяет создать вторую.
в этом случае следующим запросом выполняй UPDATE SET hit_count = hit_count + 1 WHERE site_id = ? AND hit_day = СЕГОДНЯ

 

[4m@t!c]

Т.е. есть смысл в том, что бы не создавать групповые запросы стандартной выборкой. а делать это так "сказать" налету??? Реляционность БД будет искусственной? Или все таки это оправдано?