|
|
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
Попалась довольно интересная задача на DB2 на магистратуре, решил ее двумя вариантами, но не знаю, какой из них лучше, и возможно я вообще изобретаю велосипед и есть другие варианты проще. Биржа акций. Покупатели назначают максимальную цену за акцию (limit), за которую готовы купить, и количество (buy_c). Продавцы назначают минимальную цену за акцию (limit), за которую согласны продать, и количество (sell_c). Необходимо составить сводную таблицу: по каждому лимиту сколько акций может быть продано и сколько может быть куплено. Для упрощения задачи предположим, что исходные данные содержатся в следующего вида таблице Код: plaintext Для примера возьмем данные: Код: plaintext 1. 2. 3. 4. Но эта таблица не учитывает, что при наличии покупателя, готового купить за более высокую цену, продавец может продать дороже и, следовательно, больше. То есть: продавец за 20$ на самом деле может продать 3+1=4 товара: покупатель, готовый купить товар за 30$, купит и за 20$. Поэтому sell_c для 20$ должен быть 4: своего рода получается накопительный итог сверху вниз. И наоборот: готовый купить за 20$ может купить не только 5 акций за эту цену, но и 11 более дешевых. Здесь накопительный итог идет снизу вверх. Для исходных данных ответ должен быть таким: Код: plaintext 1. 2. 3. 4. Вариант решения в лоб, с двумя JOIN исходной таблицы с самой собой не работает. Когда таблицы две - все ОК, но когда появляется третья, итог считается для каждой из возможных комбинаций и в итоге цифры увеличиваются в несколько раз. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Рабочий вариант 1: соединить таблицу с самой собой, а JOIN-предикаты перенести в агрегатные функции Плюсы: короткий, читабельный, отлично scale-ится Код: sql 1. 2. 3. 4. 5. 6. 7. Рабочий вариант 2: в подзапросах посчитать отдельно количество акций, которые можно купить, и отдельно - которые можно продать, а потом объединить их FULL JOIN'ом Плюсов особых не вижу, просто этот вариант пришел первым в голову :-) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Исходные данные для удобства тестирования: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Заранее спасибо за ответы/советы/мнения! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 01:00 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
Разумеется, вариант 2 можно облагородить, выделив подзапросы в common table expressions через WITH .. AS, но сути дела это не меняет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 01:04 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
.det, а с чего ты взял, что эту задачу вообще надо решать на SQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 01:52 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
MasterZiv, это часть условия ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 03:23 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
.det, .detbuy_c limit sell_c ------ ------ ------ 1 30$ 2 3 20$ 5 7 10$ 11Почему при снижении цены за акцию растет количество продаваемых акций? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 08:34 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
.detMasterZiv, это часть условия да не, это идиотизм. ты на свои запросы погляди. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 09:37 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
Egoр, потому что биржа работает не в режиме реального времени. Она собирает все заявки и потом, в конце дня, производит анализ, ценообразование и распределение акций по хитрым правилам. Данная сводная таблица отражает покупательскую способность (и "продавательское желание") по ценам. Если покупатель в своей заявке указал, что он готов купить за 30$, а все покупатели готовы продать по 20$, и в конце дня будет установлена цена 20$ (допустим), то сделки пройдут по этой цене (а жадоморы продавцы, которые ставили по 30$, попросту ничего не продадут). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 12:19 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
.det, спс за разъяснения. на оракле задача решается за один проход без джойнов. может на DB2 тож есть какие-то аналитические функции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 12:25 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
.detEgoр, потому что биржа работает не в режиме реального времени. Ой. Это какая биржа так работает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 12:27 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
MasterZiv, автор задания - один из разработчиков IBM DB2, семь лет работавший в силиконовой долине, профессор и продекан кафедры информатики крупного технического университета. Полный текст задания прикреплен, если я где-то неправильно объяснил или упростил. И что не так с запросами, особенно с вариантом 1? В целом вспоминаются слова с таблички кабинета для совещаний на прошлом месте работы: "Если специалист хочет решить проблему - он ищет способы, если не хочет - причины" . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 12:28 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
Egoр, в том и состоит мой вопрос - есть ли способы решить задачу проще, чем я, и каковы они. Как решить ее в Oracle без JOINов или хотя бы в сторону каких функций смотреть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 12:31 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
.det, Так оно решается на Oracle: Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 12:37 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
Egoр, кстати для перечисленного мною примера биржей будет установлена цена в 10$ так как при ней объем сделок будет максимальным (11) - это считается идеальной ситуацией, когда цена для такого объема лишь одна. Если смотреть полное задание, то там еще есть понятие backlog, оно используется для других ситуаций, когда максимальный объем сделок возможен при разных ценовых лимитах, и отражает избыток спроса или предложения на рынке. При избытке спроса выбирается максимальная цена, при избытке предложения - минимальная. Всего возможно семь разных ситуаций. Кот Матроскин, не уверен, как работает настоящая биржа и меня это особо не интересует - это всего лишь часть искусственного условия университетской задачи :-) Но, думаю, автор основывался на реальных событиях, когда составлял условие :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 12:39 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
Egoр, долбаный partition, никогда им не пользовался, спасибо огромное!!! Надо почитать про него на досуге, в третьей части проекта будет OLAP))) У нас почему-то в первой части проекта для одного из заданий было выделенное условие - посчитать Dense_rank и Row_number не используя partition, вот я по инерции и во вторую часть задания это условие с собой перенес... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 12:43 |
|
||
|
Нарастающие в обоих направлениях итоги
|
|||
|---|---|---|---|
|
#18+
Решил полную задачу 19178216 А есть ли какой-нибудь способ посчитать backlog-и в подзапросе, чтобы все сделать одним запросом? Я так думаю, что на производительность это не влияет, но может быть можно еще проще и читабельней? Код: 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. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2016, 18:36 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=39236208&tid=1540341]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
162ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 260ms |

| 0 / 0 |

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