т.е. если допустим 2 даты: 01-02-16 и 02-01-16 то не важно. должно идти сначала 01й месяц потом 02?
Т.е. вам нужно отсортировать записи именно по дням месяца и не важно какой год?
Стандартными средствами MySQL это сделать нельзя. Вы можете создать отдельную таблицу с днями с помощью JOIN соединять ее с Вашим результатом, но это плохая практика. Лучше на стороне скрипта который обрабатывает результат пробежаться по полученным данным и добавить не достающие.
поточу что нужно использовать JOIN... Если запрос не сложный и данных не много тогда не критично, но если запрос сложный и большие объемы данных он скажется на скорости выполнения....
Максим Федоров: мне кажется вы преувеличиваете затраты на join. К тому же присоединять календарь надо к результирующему набору. А это не настолько затратно. Зато такая таблица решает множество проблем.
ну не скажите, представим такую задачу есть GPS трекер, где у каждой компании есть свой пул автомобилей.
Так же у нас есть отчет содержащий подневно информацию о суммарном расходе топлива для всех машин компании.
Таблица отчета имеет такую структуру:
- идентификатор
- дата, тип date, вес 3 байта
- сумма, ну допустим возьмем float, вес 4 байта.
Теперь у нас стоит задача вывести по конкретной компании отчет за текущий месяц, в котором будет информация о всех днях месяца.
В текущем месяце у компании имеется всего 3 записи (3 дня машины ездили, оставшиеся 28 нет)
Для начала мы выбираем данные по компании - с этим проблем нет.
Но что будет если мы используем таблицу-календарь и заджойним получившуюся выборку с ней?
1. Джойн в самом простом варианте это два цикла (один вложенный в другой), таким образом для получения результата мы получаем 3*31=93 итераций.
2. После осуществления всех операций наш результат будет 31 запись по 7 байт каждая - всего 217 байт. Далее эти 217 байт передаются с сервера MySQL в оболочку который его использует (передача данных тоже занимает какое-то время)
Если же мы недостающие даты будем проставлять в оболочке, без использования джойнов:
1. Мы можем доставить недостающие даты приблизительно за 34 итерации
2. В результате простой выборки из БД в оболочку будет доставлено всего 3 записи общим размером 21 байт, а не 217
Конечно если объемы системы небольшие, и запросы не частые - можно заджойнить и не парится, но если громадные нагрузки второй вариант будет оптимальнее первого