Во-первых: Речь не о хитах, а о посетителях.
Во-вторых: Эту цифру автор просто выдумал. Видимо, чтобы показать, что ограничения все таки есть
В-третьих: Далеко не каждый проект имеет столько посетителей в месяц.
Я предлагал автору этот вариант.
По-моему мнению это запрос наиболее хорошо решает задачу в самой первой постановке и очень подходит для этой статьи, так как реализует именно особенность работы MySQL с GROUP BY в без агрегирующих функций, что в других СУБД может оказаться ошибочным.
Только обязательно укажите как Вы поставили задачу с самого начала, а потом новую постановку, а то получается, что мы здесь ерунду пишем в комментариях.
Вы знаете сколько дополнений к стандартам практически в любой СУБД (MySQL, MSSQL, PostgreSQL, ORACLE, ...)?
Если говорить о миграции, то речь скорее надо поднимать об использовании уровня абстракции над СУБД, но никак не отказываться от всяких вкусностей, которые предлагают различные СУБД.
>> payments (id INT, uid INT, pay_date DATETIME, amount DECIMAL(15, 2))
Я один вижу в этой таблице тип DATETIME?
Автор поступил очень не красиво и поправил структуру таблицы в статье, после того как появились большинство комментариев на эту тему (примерно 15.08.2012 00:15).
Но даже поле типа DATETIME в данном случае Вас не спасет. Все равно будут дубликаты, но с точнотью до секунды, а не до дня.
>> даже в обычных запросах сам автор сделал ошибку ...
В данном случаи из этого следует, что автор плохо разбирается в СУБД MySQL и крайне не внимательный, а не то, что он рассказал, что то сложное и интересное.
Он просто даже не потрудился протестировать свои запросы.
И что Вам даст DATETIME?
Он Вам даст те же проблемы, но с точностью до секунды, а не до дней, что собственно ничего не меняет. Ваш запрос все равно будет возвращать дубликаты.
>> Добавление записи с разницей < 1 секунду маловероятно.
Вы это серьезно?
>> Niga доказал правильность запроса.
Он ошибся со структурой таблицы, и я ему это сразу пояснил. Не верите? возьмите и проверьте. Всё увидите своими глазами.
Вы правы.
При наличии индексов у полей f1 и f2 запрос предложенный автором в реальности (за исключением специально подогнанных случаев) будет работать заметно медленнее, чем запрос, который автор называет не оптимальным.
Во-вторых: Эту цифру автор просто выдумал. Видимо, чтобы показать, что ограничения все таки есть
В-третьих: Далеко не каждый проект имеет столько посетителей в месяц.
Полагаю, что это для демонстрации Affix’а
По-моему мнению это запрос наиболее хорошо решает задачу в самой первой постановке и очень подходит для этой статьи, так как реализует именно особенность работы MySQL с GROUP BY в без агрегирующих функций, что в других СУБД может оказаться ошибочным.
Вы знаете сколько дополнений к стандартам практически в любой СУБД (MySQL, MSSQL, PostgreSQL, ORACLE, ...)?
Если говорить о миграции, то речь скорее надо поднимать об использовании уровня абстракции над СУБД, но никак не отказываться от всяких вкусностей, которые предлагают различные СУБД.
Может Вы еще посоветуете не использовать специцифичные для СУБД ORACLE фишки?
Я один вижу в этой таблице тип DATETIME?
Автор поступил очень не красиво и поправил структуру таблицы в статье, после того как появились большинство комментариев на эту тему (примерно 15.08.2012 00:15).
Но даже поле типа DATETIME в данном случае Вас не спасет. Все равно будут дубликаты, но с точнотью до секунды, а не до дня.
В данном случаи из этого следует, что автор плохо разбирается в СУБД MySQL и крайне не внимательный, а не то, что он рассказал, что то сложное и интересное.
Он просто даже не потрудился протестировать свои запросы.
Он Вам даст те же проблемы, но с точностью до секунды, а не до дней, что собственно ничего не меняет. Ваш запрос все равно будет возвращать дубликаты.
Вы понимаете, что результат запроса зависит от структуру таблицы?
Вы это серьезно?
>> Niga доказал правильность запроса.
Он ошибся со структурой таблицы, и я ему это сразу пояснил. Не верите? возьмите и проверьте. Всё увидите своими глазами.
Нет, тут дело в не правильно построенном запросе.
У него поле pay_date типа DATE.
При наличии индексов у полей f1 и f2 запрос предложенный автором в реальности (за исключением специально подогнанных случаев) будет работать заметно медленнее, чем запрос, который автор называет не оптимальным.
Какая цель была вашей учебы в ВУЗе?
>> Если человеку не хватает мозгов, то специалист из него не выйдет, хоть что с ним делай.
Значит всё-таки зависит от человека.