|
|
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78Что касается НЕНАДЁЖНЫХ, то именно выделенное является недостатком UNION, потому что все UNION должны иметь одинаковое кол-во столбов. То что вы выделили я как раз не использую, оно там ради того, чтобы работало то, что НЕ выделено ;) Другого способа не нашёл...У UNION не бывает ненадежных результатов, в отличие от GROUP BY. В полях `l` (во всех трех частях) и `money` (в первой части) в результате запроса может быть мусор. Кстати, почему в двух часть запроса `summ` AS `money`, а в третьей SUM(`summ`) AS `money` ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 12:35:27 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksofttip78Что касается НЕНАДЁЖНЫХ, то именно выделенное является недостатком UNION, потому что все UNION должны иметь одинаковое кол-во столбов. То что вы выделили я как раз не использую, оно там ради того, чтобы работало то, что НЕ выделено ;) Другого способа не нашёл... У UNION не бывает ненадежных результатов, в отличие от GROUP BY. В полях `l` (во всех трех частях) и `money` (в первой части) в результате запроса может быть мусор. Кстати, почему в двух часть запроса `summ` AS `money`, а в третьей SUM(`summ`) AS `money` ? потому что я использую только последний, а из первых двух - нет я же говорю: я не использую этот мусор в тех отмеченных местах, там `l` и `summ` только для того, чтобы кол-во столбов совпало с остальными UNION в коде он НЕ используется "ненадёжный" это не мой термин, а товарища выше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 14:59:34 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksofttip78одно дело, когда БД будет группировать/складывать, а другое - когда ПХП нифига они не "абсолютно одинаковы", потому что движки разные и подходы в пхп это ассоциативный массив группирует значения по датам возможно всё это экономия на спичках, по идее в БД всё это быстрее сделать переформулирую вопрос: этот запрос оптимален? Я не понял, причем тут ассоциативный массив. Но если выборка велика (десятки тысяч записей и более), то с точки зрения MySQL быстрее выполнить три отдельных запроса, нежели их объединение с помощью UNION ALL (речь не идет про простой UNION). Поэтому если PHP-код просто линейно выводит данные куда-то или работает всегда только с текущей записью, то выгоднее выполнить три отдельных запроса. при том, что во всех 3х UNION используется одна и та же таблица вместо этого я могу сделать 1 SELECT, потом через ПХП сгруппировать по дате все данные в хэш-массиве, просуммировать и разложить в таблице, как мне надо это будет 1 запрос, но нагрузка переместится на скрипт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 15:01:40 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78потому что я использую только последний, а из первых двух - нет я же говорю: я не использую этот мусор в тех отмеченных местах, там `l` и `summ` только для того, чтобы кол-во столбов совпало с остальными UNION в коде он НЕ используется Тогда стоит убрать поле `l` из SELECT-а, а в тех местах, где `money` не используется, вписать, например, 0. И MySQL-ю чуток полегче будет, и сопровождаемость повысится. Кстати, если я ничего не путаю, то можно переписать запрос так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 15:15:51 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
Если по конретному `ref` отбирается очень много записей, то имеет смысл в WHERE сделать дополнительный фильтр по дате, это будет быстрее, чем LIMIT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 15:19:26 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksoftКстати, если я ничего не путаю, то можно переписать запрос так: вот! Я знал, что нет предела совершенству. спасибо miksoftЕсли по конретному `ref` отбирается очень много записей, то имеет смысл в WHERE сделать дополнительный фильтр по дате, это будет быстрее, чем LIMIT. мне нужно именно 32 строчки выдать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 16:32:06 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
есть какой-то способ из int-полей БД выводить в пхп не 0, а сразу '' (пустышку) ? а то каждую ячейку проверять приходится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 16:35:42 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78miksoftЕсли по конретному `ref` отбирается очень много записей, то имеет смысл в WHERE сделать дополнительный фильтр по дате, это будет быстрее, чем LIMIT.мне нужно именно 32 строчки выдать...Это никак не противоречит моему предложению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 16:56:17 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78есть какой-то способ из int-полей БД выводить в пхп не 0, а сразу '' (пустышку) ? а то каждую ячейку проверять приходитсяМожно точно так же проверять в MySQL - IF(field<>0, field, NULL) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 16:58:22 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksofttip78пропущено... мне нужно именно 32 строчки выдать...Это никак не противоречит моему предложению. в смысле сделать WHERE `added` IN (...) ? я не знаю всех дат, они идут не подряд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 18:04:24 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78miksoftпропущено... Это никак не противоречит моему предложению. в смысле сделать WHERE `added` IN (...) ? я не знаю всех дат, они идут не подряд В смысле сделать WHERE `added` > сегодня - 60 дней Если, конечно, запас можно хоть как-то прогнозировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 18:25:23 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksoftВ смысле сделать WHERE `added` > сегодня - 60 дней Если, конечно, запас можно хоть как-то прогнозировать. не, это вообще не вариант суть - вывести именно 99 последних записей, а не дней там могут быть пробелы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 18:53:37 |
|
||
|
|

start [/forum/topic.php?fid=47&startmsg=39062328&tid=1832683]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
80ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 417ms |

| 0 / 0 |
