Посоветуйте как правильно спроектировать БД?

Сразу обговорю один момент. Сделать свою систему счетчиков мне действительно нужно, в каком то плане я изобретаю велосипед, но в поставленной задаче это единственное решение. Разумеется я знаю такие слова как Liveinternet и Google Analytics, мало того, я этим активно пользуюсь.

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

1) Узнать количество уников для данного ресурса за текущие сутки
2) Узнать количество просмотров для данного ресурса за текущие сутки
3) Узнать количество уников для данного ресурса за текущий месяц
4) Узнать количество просмотров для данного ресурса за текущий месяц
5) Узнать количество уников для данного ресурса за все время
6) Узнать количество просмотров для данного ресурса за все время
7) Данные для графика - посуточный за текущий месяц
8) Данные для графика - помесячный за все время

Изначально для данных счетчика я сделал толко три таблицы.
Ниже указаны схемы этих таблиц в интерпретации Doctrine ORM.

Код (Text):

1.  
2. CounterQuery:
3.   columns:
4.     id:
5.       primary: true
6.       autoincrement: true
7.       type: integer(10)
8.     url: string(2048)    
9.     resource_id: integer(10)
10.     visitor_id: integer(10)
11.     query_time: timestamp    
12.   relations:
13.     Resource:
14.     Visitor:
15.   options:
16.     type: INNODB
17.     collate: utf8_unicode_ci
18.     charset: utf8
19.  
20. Visitor:
21.   columns:
22.     id:
23.       primary: true
24.       autoincrement: true
25.       type: integer(10)
26.     query_time: timestamp
27.     visitor_ip: integer(10)
28.   relations:
29.     CounterQuery:
30.       local: id
31.       foreign: visitor_id          
32.   options:
33.     type: INNODB
34.     collate: utf8_unicode_ci
35.     charset: utf8
36.  
37. Resource:
38.   columns:
39.     id:
40.       primary: true
41.       autoincrement: true
42.       type: integer(10)
43.     name: string(255)
44.     url: string(2048)
45.     resource_ip: integer(10)
46.     subscriber_ip: integer(10)
47.     registration_date: timestamp
48.     account_number: integer(10)
49.     description: clob
50.   relations:
51.     CounterQuery:
52.       local: id
53.       foreign: resource_id
54.   options:
55.     type: INNODB
56.     collate: utf8_unicode_ci
57.     charset: utf8

Как работает сам счетчик, при обращении, берется Cookie, эта кука в зашифрованном виде содержит visitor id, соответственно, если я вижу что такой visitor id есть, то в таблицу counter_query добавляю запись, если куки нет, или кука не валидная (visitor id отсутствует) создаю новый visitor, устанавливаю куку и создаю запись в counter_query. Что получаем: таблицу в которой содержаться все записи запросов счетчика и таблица фактических посетителей. Кука устанавливается на один год.

В текущей схеме появились трудности при выборке из базы данных для графиков - по суткам, по месяцам. Так же есть предположение что при серьезных размерах таблицы counter_query запросы будут выполняться очень долго, причем это время будет расти по ходу увеличения таблицы.

Что хочеться получить в ходе обсуждения:
1) Конструктивную критику
2) Предложения как сделать грамотно, чтобы в дальнейшем вышепоставленные задачи можно было расширить, например выбрать ядро аудитории за год и т.д. и т.п.

P.S. я опустил в описании выше добавление индексов к таблицам - разумеется без этого в данной задаче не обойтись.