Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
27.04.2017, 09:19
|
|||
|---|---|---|---|
|
|||
Запрос: просуммировать по месяцу |
|||
|
#18+
Есть простой запрос, выбирающий оплаты и их даты по id дела: Код: sql 1. 2. 3. 4. paymentdate_payment123.192015-01-01345.492015-01-02146362.052015-12-016750.582015-12-131523.092015-12-14157524.192016-01-01150413.492016-02-01 Можно ли и как средствами SQL выбрать суммы оплат за каждый месяц каждого года? Для примера выше должно получиться: paymentdate_payment_YYYY_MM468.682015-01154635.722015-12157524.192016-01150413.492016-02 Подскажите, как это реализовать, пожалуйста! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.04.2017, 09:28
|
|||
|---|---|---|---|
Запрос: просуммировать по месяцу |
|||
|
#18+
DATE_FORMAT() + GROUP BY + SUM() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.04.2017, 09:47
|
|||
|---|---|---|---|
|
|||
Запрос: просуммировать по месяцу |
|||
|
#18+
AkinaDATE_FORMAT() + GROUP BY + SUM() Код: sql 1. 2. 3. 4. 5. Спасибо. Это правильное решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.04.2017, 09:52
|
|||
|---|---|---|---|
Запрос: просуммировать по месяцу |
|||
|
#18+
Вполне. Только ORDER BY здесь избыточен - группировка выполняет одновременно и сортировку, повторно этого делать не требуется, выражение сортировки-то одно и то же. Ну и алиас полю вывода суммы, наверное, не помешает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.04.2017, 09:54
|
|||
|---|---|---|---|
|
|||
Запрос: просуммировать по месяцу |
|||
|
#18+
Akina, Большое спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.04.2017, 10:14
|
|||
|---|---|---|---|
|
|||
Запрос: просуммировать по месяцу |
|||
|
#18+
AkinaТолько ORDER BY здесь избыточен - группировка выполняет одновременно и сортировку, повторно этого делать не требуется, выражение сортировки-то одно и то же. Я бы не стал завязываться на этот побочный эффект. А вдруг в следующем выпуске MySQL научится делать hash group by и сортировка при группировке выполняться не будет (как это было, например, в Oracle при переходе с версии 9i на 10g)? В стандарте сказано вполне себе однозначно - сортировку результирующего набора данных обеспечивает и гарантирует только предложение ORDER BY... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.04.2017, 10:32
|
|||
|---|---|---|---|
Запрос: просуммировать по месяцу |
|||
|
#18+
В данном конкретном случае - может и да. Но ORDER BY производит сортировку безусловно, не обращая внимания на совпадение выражений, что на больших наборах даёт изрядный и в пень не нужный оверхед. Добрый Э - Эхвдруг в следующем выпуске MySQL ... сортировка при группировке выполняться не будетВ будущих версиях, видимо, сделают хитрее (во всяком случае, если верить текущим бетам) - если в выражении группировки присутствует модификатор ASC или DESC, то результат сортируется по выражению группировки, а если модификатор в выражении группировки отсутствует, то сортировка не выполняется. И это даже описано в драфте 8-й версии мануала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=47&mobile=1&tid=1830723]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
31ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 10ms |
| total: | 118ms |

| 0 / 0 |
