Кстати, вопрос я решил этот.
Не нужно ни в коем случае писать условия в тег link.
То есть подключаем второй файл css, а уже внутри него делаем условия media
Спасибо за Ваши советы. На счет ключа остановился на этом варианте, для моих целей вполне приемлем $id = md5($_SERVER['REMOTE_ADDR'].date('Y-m-d H').$id_product);
Ну а по логике, пусть накручивают понемногу, мне главное, чтобы такие методы, как залипание F5 (образно) или тот же DOS не вывел из строя систему.
Ну мне надо где-то хранить просмотры по ip! Если например в первой таблице важна только 1 цифра это сколько всего пррсмотрели, то вторая таблица (статистики и ip) как раз и нужна для "сырых" данных, черновой работы. Я в комменте выше, задал вопрос, про проверку даты. Правильно это или нет? И касаемо ключа, лучше использовать char32 и в php его делать на основании md5(id+product_id) ? Вы это имели ввиду?
У меня на 1 товар всегда приходится сколько то просмотров. От 0 и выше. Поэтому данное поле лучше оставить в таблице товаров. В принципе, я и кроном могу его обновлять. Другое дело, основная таблица именно статистики. Вот по не и непонятно. Тоесть мне проверять дату через now() - interval 1 hour так? Может как то можно, что запрос кэшировался, а не пересчитывался каждый заход?
Спасибо за такой ответ расширенный. У меня числовые индексы. Я попробовал сделать отдельные индексы и составные, и не пойму в них разницы. В выборке используется обязательно эти 2 поля. firma и produc. Разницы в скорости нет между отдельным индексом и составным.
Но проблема решена, прирост с созданием таких индексов ускорил до 1 сек запрос с 50, поэтому думаю вопрос решен на первое время. Касаемо GUID я пока не изучал, но мысль неплохая.
Не нужно ни в коем случае писать условия в тег link.
То есть подключаем второй файл css, а уже внутри него делаем условия media