Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Предположим, запрос такой: SELECT worker, SUM(ordersum) as worker_sum FROM workeroder GROUP BY worker ORDER BY worker_sum; Хотелось бы ограничить объем выборки таким образом, чтобы сумма в столбце worker_sum не превышала некоторую константу. Как это лучше всего сделать? Спасибо! (ASA 9) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 19:08 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
LeviathanЗдравствуйте! Предположим, запрос такой: SELECT worker, SUM(ordersum) as worker_sum FROM workeroder GROUP BY worker ORDER BY worker_sum; Хотелось бы ограничить объем выборки таким образом, чтобы сумма в столбце worker_sum не превышала некоторую константу. Как это лучше всего сделать? Спасибо! (ASA 9) попробуй так: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 19:27 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Замечу, что это стандартнейшая задача, одинаково решающаяся во всех SQL'ях. Называется: наложение условия на результат группировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 23:25 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
komrad, A.K., если я правильно понял, вы предлагаете наложить условие на результат каждой группировки. Мне же нужно наложить условие на совокупность таких группировок. Я плохо выразился: надо ограничить сумму значений в столбце worker_sum _по всем строкам результата_. komrad, ваш вариант ограничит сумму по КАЖДОМУ воркеру. Мне же надо ограничить сумму по столбцу. Пример: |Воркер|Сумма| |1| 100| |2| 200| |3| 300| Ограничение было 600 - дальше не селектится. A.K., вполне допускаю что это стандартнейшая задача. Но до меня не доходит, опыта не хватает... хотя чувствую решение лежит где-то на поверхности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 00:01 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Подобная задача обсуждалась, поиском посмотрите. Проще всего сделать хранимую процедуру, в ней курсором пройтись по запросу предложенному kompad, подсчитывая сумму, сравниваем с константой и сохраняя во временную таблицу будущий результат. Результат - select из временной таблицы. А "константу" можно в процедуру параметром передавать для красоты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 01:03 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Еще можно попробовать OLAP функции в 9 версии. В BOL в разделе Window functions есть даже пример подсчета нарастающего итога в поле. Остается видимо наложить ограничение на этот итог(вашу константу). Хотя не уверен, что можно так сделать. Надо попробовать на досуге. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 01:36 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
antand, поиском пытался :) Но видимо у меня какие-то другие ключевые слова ассоциируются с такой проблемой. Спасибо, попробую курсором. Думал об этом, но все-таки надеялся что можно как-то сделать одним запросом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 09:04 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Leviathan ваш вариант ограничит сумму по КАЖДОМУ воркеру. Мне же надо ограничить сумму по столбцу. Пример: |Воркер|Сумма| |1| 100| |2| 200| |3| 300| Ограничение было 600 - дальше не селектится. В такой постановке задача действительно не решается одним SELECT'ом, по крайней мере в 8-ке, где нет аналитических функций. Пишите хранимую процедуру, возвращающую рекордсет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 10:18 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
A.K.В такой постановке задача действительно не решается одним SELECT'ом, по крайней мере в 8-ке, где нет аналитических функций.Ещё как решается. И в один селект, и без аналитических функций. Вот только нужно ли оно, такое решение, которое ставит сервер на колени? Ну разве только для оттачивания мастерства в написании хитровыгнутых запросов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 04:30 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
В 9-ке действительно лучше использовать OLAP функцию: примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. авторВот только нужно ли оно, такое решение, которое ставит сервер на колени? Ну разве только для оттачивания мастерства в написании хитровыгнутых запросов... ASA 9 OLAP функции давольно таки грамотно выполняет. Да и "обычные хитроумные" запросы делает спокойно (если конечно грамотно написаны). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 10:29 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Бабичев СергейЕщё как решается. И в один селект, и без аналитических функций. Вот только нужно ли оно, такое решение, которое ставит сервер на колени? Ну разве только для оттачивания мастерства в написании хитровыгнутых запросов... Согласен, что решается. Только как раз мастерства от написания такого запроса много не прибавится Новички в SQL, к примеру, очень любят городить трехэтажные подзапросы там где достаточно простого JOIN'а. Здесь с вычислением суммы нарастающим итогом будет примерно то же самое - решение с суперизбыточным совокупным объемом выборок. Imho мастерство - это в данном случае умение решить задачу оптимальным образом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 10:53 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Сергей, вы имеете в виду решение в следующем стиле: отбирать в правильном порядке, подсчитывая на каждом шага сумму по уже отобранным значениям? Что-то такое вертится в голове, но опыт не позволяет быстро реализовать... Да, и мрачновато выглядит перспектива с каждой новой строкой пересчитывать всю сумму. Volokola, большое спасибо, попробую применить! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 10:55 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
LeviathanСергей, вы имеете в виду решение в следующем стиле: отбирать в правильном порядке, подсчитывая на каждом шага сумму по уже отобранным значениям? Что-то такое вертится в голове, но опыт не позволяет быстро реализовать... Да, и мрачновато выглядит перспектива с каждой новой строкой пересчитывать всю сумму. Volokola, большое спасибо, попробую применить!Да, примерно это я и имел ввиду. Ну или если пояснить на примере, то вот так всё будет выглядеть: Пусть есть таблица TEST, содержащая в себе записи вида: workerordersum12013015021102903140316047041305500 Внимательно смотрим на результаты работы вот такого запроса: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Теперь достаточно перенести подзапрос из SELECT-листа во фразу HAVING и получим то, что нужно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:05 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
и для таблицы с миллионом воркеров получим миллион сканов таблицы подзапросом. даже если сканы по индексу - результата не скоро дождетесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:20 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
A.K.и для таблицы с миллионом воркеров получим миллион сканов таблицы подзапросом. даже если сканы по индексу - результата не скоро дождетесь.А я сразу сказал, что такое решение поставит сервер на колени... Запрос же был приведен исключительно для того, чтобы показать ошибочность высказывания: A.K.В такой постановке задача действительно не решается одним SELECT'ом, по крайней мере в 8-ке, где нет аналитических функций. Как видишь - задача решилась в один select-statement... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:30 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
To Бабичев Сергей Это все хорошо, но кто Вам сказал что t1.worker <= t0.worker Посмотрите на начальный запрос Автора ORDER BY worker_sum ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:33 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Бабичев СергейКак видишь - задача решилась в один select-statement... практическая ценность этого решения = 0, поэтому я такие решения даже не рассматриваю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:36 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
antandTo Бабичев Сергей Это все хорошо, но кто Вам сказал что t1.worker <= t0.worker Посмотрите на начальный запрос Автора ORDER BY worker_sumASA 9 перестала понимать derived-таблицы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:41 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
A.K. Бабичев СергейКак видишь - задача решилась в один select-statement... практическая ценность этого решения = 0, поэтому я такие решения даже не рассматриваю.Практическая ценность этого решения может и ноль. Но решать это автору вопроса ;) Хотя, я и сам обоими руками за "убиение" тех, кто такие запросы пишет в промышленно эксплуатируемых системах. Важен был сам факт - любое решение с аналитическими функциями можно написать и без них. Другое дело - насколько это понизит производительность сервера... З.Ы. Всё сугубо моё IMHO, никому ничего не навязываю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:44 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Не в этом дело. Если я правильно понял, автору нужно сначала просуммировать с группировкой все записи, потом отсортировать их по сумме и только потом вытащить записи, подсчитывая нарастающий итог в поле и ограничивая выборку по нарастающему итогу. В вашем случае сработает т.к. у Вас сортировки нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:46 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
antandНе в этом дело. Если я правильно понял, автору нужно сначала просуммировать с группировкой все записи, потом отсортировать их по сумме и только потом вытащить записи, подсчитывая нарастающий итог в поле и ограничивая выборку по нарастающему итогу. В вашем случае сработает т.к. у Вас сортировки нет.Я понял твой вопрос и в первый раз. Поэтому и спросил - что останавливает использовать деривед-таблицу? З.Ы. Правда запрос станет ещё более неподъемным для сервера... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:50 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
antandНе в этом дело. Если я правильно понял, автору нужно сначала просуммировать с группировкой все записи, потом отсортировать их по сумме и только потом вытащить записи, подсчитывая нарастающий итог в поле и ограничивая выборку по нарастающему итогу. В вашем случае сработает т.к. у Вас сортировки нет. И в этом тоже. Не знаю как в девятке, но в восьмерке AFAIR нельзя сортировать и нумеровать строки в результатах поздапросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 11:52 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
A.K. antandНе в этом дело. Если я правильно понял, автору нужно сначала просуммировать с группировкой все записи, потом отсортировать их по сумме и только потом вытащить записи, подсчитывая нарастающий итог в поле и ограничивая выборку по нарастающему итогу. В вашем случае сработает т.к. у Вас сортировки нет. И в этом тоже. Не знаю как в девятке, но в восьмерке AFAIR нельзя сортировать и нумеровать строки в результатах поздапросов.Ладно, парни. Поставлю свой сервер ещё раз на колени... Пусть есть таблица TEST с такими данными: WORKERORDERSUM 0500 1500 270 2130 2200 3140 3160 4110 490 520 530 550 Внимательно смотрим на результат работы запроса: Код: plaintext 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. 28. 29. 30. 31. 32. 33. 34. З.Ы. 2 автор запроса и ALL: Никогда не используйте такие запросы в промышленных системах!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 12:12 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Бабичев СергейЯ понял твой вопрос и в первый раз. Поэтому и спросил - что останавливает использовать деривед-таблицу? З.Ы. Правда запрос станет ещё более неподъемным для сервера... Что-то я не пойму вашу идею. Можем на меня праздники сказываются... При чем тут деривед-таблица? Сортировка нужна сначала перед подсчетом нарастающего итога. Вот итог вашего первого запроса WORKER WORKER_SUMM SLIDE_SUMM ------ ----------- ---------- 1 100 100 2 200 300 3 300 600 4 200 800 5 500 1300 Он неправилен для автора Нужно 1 100 100 2 200 300 4 200 500 3 300 800 5 500 1300 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 12:14 |
|
||
|
Запрос с проверкой суммы по столбцу в результате
|
|||
|---|---|---|---|
|
#18+
Всем огромное спасибо за участие, особенно Сергею! Было очень интересно увидеть решение в один запрос. Когда я устраивался на работу, была поставлена задача сделать подобные вещи ОДНИМ запросом. Ну и поломал же я мозг! Все же такие запросы имеют несомненную ценность как головоломки! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2006, 12:17 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=34229680&tid=2012330]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 357ms |

| 0 / 0 |
