|
|
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
вот есть таблица: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. и мне из неё надо исполнить html-таблицу, где я группирую данные по дням/месяцам/годам, в которой могут быть следующие виды данных: l=0 l<>0 & summ=0 l<>0 & summ>0 запрос выглядит так: Код: sql 1. 2. 3. 4. 5. собс-но вопрос: 3 SELECT-а через UNION это правильная мера или надо таки делать 1 SELECT и в пхп разруливать это всё ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 20:49:48 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78собс-но вопрос: 3 SELECT-а через UNION это правильная мера или надо таки делать 1 SELECT и в пхп разруливать это всё ? это вообще без разницы просто дело вкуса мы в своих проектах делаем три разных запроса это потому что у нас очень высокая степень изменяемости программного кода и поэтому нам важно изначально строить архитектуру на основе максимальной живучести кода к изменениям максимальная живучесть обеспечивается на трех отдельных запросах но если я правильно понял ваш вопрос, то вам вообще не на этот форум потому что конкретно по mysql у вас вопроса нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 21:23:45 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78, 1) Первое и самое опасное - вы используете в секциях SELECT и ORDER BY те поля, которых нет в группировке. Значения для этих полей будут выбраны из произвольных записей в пределах группы. 2) Вместо 1,1,1 в первом поле результата, вероятно, предполагается 1,2,3 ? 3) Во втором SELECT-е поля группировки и сортировки отличаются от других. Это опечатка или так надо? 4) Вместо UNION лучше использовать UNION ALL для того, чтобы MySQL не пытался сделать DISTINCT итоговому набору данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 21:42:15 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
Lumixtip78собс-но вопрос: 3 SELECT-а через UNION это правильная мера или надо таки делать 1 SELECT и в пхп разруливать это всё ? это вообще без разницы а мне вот как раз важно знать - почему без разницы? mysql кэширует 1й запрос и остальные 2 не тратят ресурсы? так то 3 запроса никак не могут быть лучше 1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 22:19:27 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksofttip78, 1) Первое и самое опасное - вы используете в секциях SELECT и ORDER BY те поля, которых нет в группировке. Значения для этих полей будут выбраны из произвольных записей в пределах группы. 2) Вместо 1,1,1 в первом поле результата, вероятно, предполагается 1,2,3 ? 3) Во втором SELECT-е поля группировки и сортировки отличаются от других. Это опечатка или так надо? 4) Вместо UNION лучше использовать UNION ALL для того, чтобы MySQL не пытался сделать DISTINCT итоговому набору данных. там L маленькая в остальном да, опечатки кое-где, вот так надо: Код: sql 1. 2. 3. 4. 5. насчёт п.1 не уверен, что правильно сделал? я так понимаю, что AS `period` нельзя юзать в GROUP BY, потому что индекса на него нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 22:23:20 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
тьфу блин, вот же (редактировать сообщения нельзя до сих пор ппц) Код: sql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 22:25:57 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78я так понимаю, что AS `period` нельзя юзать в GROUP BY, потому что индекса на него нет?Нет, синтаксис и логика не зависит от наличия индексов. Индексы могут помочь только для ускорения запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 22:48:44 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78 Код: sql 1. Какие значения вы ожидаете в этих полях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 22:56:31 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksofttip78 Код: sql 1. Какие значения вы ожидаете в этих полях? цифры же Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 23:00:34 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksofttip78я так понимаю, что AS `period` нельзя юзать в GROUP BY, потому что индекса на него нет?Нет, синтаксис и логика не зависит от наличия индексов. Индексы могут помочь только для ускорения запросов. так как правильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 23:02:51 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
и разве дело всё не в ускорении запросов? индексы GROUP BY также ускоряют ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 23:05:11 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78miksoftпропущено... Какие значения вы ожидаете в этих полях? цифры же Код: sql 1. 2. Речь не о типах данных, а о логике выполнения запроса. Повторюсь:miksoftвы используете в секциях SELECT и ORDER BY те поля, которых нет в группировке. Значения для этих полей будут выбраны из произвольных записей в пределах группы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 23:25:54 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78и разве дело всё не в ускорении запросов? индексы GROUP BY также ускоряютМогут ускорят в некоторых случаях. Но я-то отвечал на конкретную цитату. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 23:26:52 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksoftвы используете в секциях SELECT и ORDER BY те поля, которых нет в группировке. Значения для этих полей будут выбраны из произвольных записей в пределах группы. что-то я потерял нить - о каких полях/логике речь? мне надо в GROUP BY запихать summ и src ?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 23:39:30 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78miksoftвы используете в секциях SELECT и ORDER BY те поля, которых нет в группировке. Значения для этих полей будут выбраны из произвольных записей в пределах группы. что-то я потерял нить - о каких полях/логике речь? мне надо в GROUP BY запихать summ и src ??Я же цитировал конкретные поля - "`summ` AS `money` ... `src`". Обращайте внимание, что цитаты не просто так делаются, а именно тех мест, о которых речь. Запихивать ли эти поля в GROUP BY - вряд ли, исходя из их названия. Возможно, их надо обернуть в агрегатную функцию, например SUM (summ) AS money. Не зная задачи этого запроса невозможно сказать точно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 23:50:08 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
miksofttip78пропущено... что-то я потерял нить - о каких полях/логике речь? мне надо в GROUP BY запихать summ и src ??Я же цитировал конкретные поля - "`summ` AS `money` ... `src`". Обращайте внимание, что цитаты не просто так делаются, а именно тех мест, о которых речь. Запихивать ли эти поля в GROUP BY - вряд ли, исходя из их названия. Возможно, их надо обернуть в агрегатную функцию, например SUM (summ) AS money. Не зная задачи этого запроса невозможно сказать точно. я потому конкретно их и упомянул, что они в цитате )) как "не зная"?? `summ` становится AS `money` и показывается в столбе таблицы - просто данные если его не сделать AS `money` в первых 2х селектах, то из-за 3го селекта будет ошибка src это источник, тоже просто данные в таблице там каждый столб это столб в <table> не понятна суть непоняток ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2015, 23:55:16 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78, Хорошо, попробую на примере. Допустим есть такие таблица и запрос: period summ src110'A'120'B'130'C' Код: sql 1. В таком случае невозможно гарантировать, что именно будет в результате. Возможен любой из вариантов: summ src10'A' summ src20'B' summ src30'C' После нескольких проб может показаться, что четко выбирается какой-то один из вариантов. Но это ложное ощущение. Результат может поменяться после любого изменения ситуации - самого запроса или, например, добавления/удаления индексов (на любой таблице, которая используется в запросе). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2015, 00:05:52 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
ну вообще я тестировал (и тестирую). Там набирается именно сумма по дням, по месяцам, по годам всё складывается пока верно были прецеденты как раз с сортировкой, когда я не `added`, а `period` юзал, но сейчас всё ок что касается `src`, то он мне не нужен в SELECT так то... он мне будет нужен во WHERE иногда, а тогда я сделаю GROUP BY `period`,`src` наверное или ещё как ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2015, 00:21:51 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78вот есть таблица: Field Type Null Key Default Extra l mediumint(8) unsigned NO MUL 0 ref mediumint(8) unsigned NO MUL 0 added timestamp NO MUL CURRENT_TIMESTAMP summ smallint(5) unsigned NO 0 bought tinyint(1) NO 0 comment varchar(255) NO src tinyint(1) NO 1 и мне из неё надо исполнить html-таблицу, где я группирую данные по дням/месяцам/годам, в которой могут быть следующие виды данных: l=0 l<>0 & summ=0 l<>0 & summ>0 запрос выглядит так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. собс-но вопрос: 3 SELECT-а через UNION это правильная мера или надо таки делать 1 SELECT и в пхп разруливать это всё ? 1. По вашему вопросу: полученные в пхп результаты абсолютно одинаковы для вариантов с одним select и с 3 select объединенными через union. Разница может быть только в скорости выполнения запросов самим MySQL. Если вы хотите "разруливать" результаты в пхп, то проще выполнить 3 запроса, не объединяя их через union. 2. В вашем запросе я выделил поля, имеющие НЕНАДЕЖНЫЕ значения (то, о чем вам говорит miksoft): эти поля не входят в список группировки, и не обрабатываются агрегатными функциями (как MIN, MAX, SUM, GROUP_CONCAT и т.п.). В стандарте SQL такой запрос будет недопустимым, однако в расширении MySQL для таких полей будет взято произвольное значение из кучи строк с одинаковыми полями группировки. Вы уверены в том, что хотите писать ненадежные приложения? Если нет - советую внимательно разобраться в этом вопросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2015, 10:21:32 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
Cygapb-007В вашем запросе я выделил поля, имеющие НЕНАДЕЖНЫЕ значения (то, о чем вам говорит miksoft)Не, ну это перебор. Константы-то зачем выделять? Они уж точно надёжные ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2015, 13:56:55 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tanglirCygapb-007В вашем запросе я выделил поля, имеющие НЕНАДЕЖНЫЕ значения (то, о чем вам говорит miksoft)Не, ну это перебор. Константы-то зачем выделять? Они уж точно надёжныеПоле так называется - L. Вот если бы было 'L' - то да, была бы константа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2015, 14:05:49 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
Cygapb-007tanglirпропущено... Не, ну это перебор. Константы-то зачем выделять? Они уж точно надёжныеПоле так называется - L. Вот если бы было 'L' - то да, была бы константа И точно! А я все никак не могу избавиться от ощущения, что это строковые литералы с единицей :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2015, 14:07:56 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
Еще забыл выделить поле ADDED, которе вообще непойми что за звэр ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2015, 14:09:00 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
Cygapb-0072. В вашем запросе я выделил поля, имеющие НЕНАДЕЖНЫЕ значения (то, о чем вам говорит miksoft): эти поля не входят в список группировки, и не обрабатываются агрегатными функциями (как MIN, MAX, SUM, GROUP_CONCAT и т.п.). В стандарте SQL такой запрос будет недопустимым, однако в расширении MySQL для таких полей будет взято произвольное значение из кучи строк с одинаковыми полями группировки. Вы уверены в том, что хотите писать ненадежные приложения? Если нет - советую внимательно разобраться в этом вопросе. Что касается НЕНАДЁЖНЫХ, то именно выделенное является недостатком UNION, потому что все UNION должны иметь одинаковое кол-во столбов. То что вы выделили я как раз не использую, оно там ради того, чтобы работало то, что НЕ выделено ;) Другого способа не нашёл... Сам запрос сейчас выглядит так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Cygapb-007tip78собс-но вопрос: 3 SELECT-а через UNION это правильная мера или надо таки делать 1 SELECT и в пхп разруливать это всё ? 1. По вашему вопросу: полученные в пхп результаты абсолютно одинаковы для вариантов с одним select и с 3 select объединенными через union. Разница может быть только в скорости выполнения запросов самим MySQL. Если вы хотите "разруливать" результаты в пхп, то проще выполнить 3 запроса, не объединяя их через union. одно дело, когда БД будет группировать/складывать, а другое - когда ПХП нифига они не "абсолютно одинаковы", потому что движки разные и подходы в пхп это ассоциативный массив группирует значения по датам возможно всё это экономия на спичках, по идее в БД всё это быстрее сделать переформулирую вопрос: этот запрос оптимален? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 12:03:24 |
|
||
|
данные из одной таблицы надо сформатировать в 3 разных вида
|
|||
|---|---|---|---|
|
#18+
tip78одно дело, когда БД будет группировать/складывать, а другое - когда ПХП нифига они не "абсолютно одинаковы", потому что движки разные и подходы в пхп это ассоциативный массив группирует значения по датам возможно всё это экономия на спичках, по идее в БД всё это быстрее сделать переформулирую вопрос: этот запрос оптимален?Я не понял, причем тут ассоциативный массив. Но если выборка велика (десятки тысяч записей и более), то с точки зрения MySQL быстрее выполнить три отдельных запроса, нежели их объединение с помощью UNION ALL (речь не идет про простой UNION). Поэтому если PHP-код просто линейно выводит данные куда-то или работает всегда только с текущей записью, то выгоднее выполнить три отдельных запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2015, 12:30:31 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39051256&tid=1832683]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
79ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 379ms |

| 0 / 0 |
