|
|
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
AmKadРавенства по номеру счета должно хватить.С удовольствием посмотрю на твое решение, учитывая что для одного счета может быть дохрена записей 4 и 5 из cum_money_in_out_hist niv76 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. и их необходимо схлопнуть учитывая условие для self join Код: plsql 1. 2. 3. Можно обойтись без джойна с помощью model, но это баловство. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2017, 21:07 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopучитывая что для одного счета может быть дохрена записей 4 и 5 из cum_money_in_out_histНу вот чтобы не гадать, пусть автор дает данные, обладающие свойствами реальных. И посмотрим, что можно с ними сделать. Правда я оперативность ответа не гарантирую, не знаю когда до оракла доберусь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2017, 21:38 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
AmKad, Автор получив ответы на свои вполне может потерять интерес к теме. Я до Оракла доберусь в 2018, но могу дать заготовку. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Думаю, очевидно, что не стоит заклыдваться что здесь по одной строке на 4 и 5. Я не тороплю. :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2017, 22:12 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopДумаю, очевидно, что не стоит заклыдваться что здесь по одной строке на 4 и 5. А если предположить, что trade_id суть идентификатор сделки, при этом интересуют только сделки, содержащие ровно по одному участнику на каждой из сторон? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2017, 01:35 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, Да там мутняк отчасти, то что я вижу это сделки в приделах одного счета. Но сделка должна быть между разными клиентами и разными валютами, что, по моему, делаеться только через SWIFT в Украине. Но вот что удивляет, что ищут MAX(settlement_id) могу только предполагать что это идентификатор валютных операций и если нет конвертации он равен 0 например. Посему мне кажеться что это и есть достаточный признак для того чтоб сказать что была конвертация. А то что не через себя (c1.client_id <> c2.client_id), можно проверить и по другому т.к. client_id - primary key. В общем очень бы хотелось увидеть пример от автора, не обязательно много (сотни) клиентов, на 2-х, 3-х все будет понятно. Потому как у меня не очень сходится если на один счет (a.account_id = 1) будет 3 клиента со сделками ct1.dc_type_id = 4 какой информативности будет единый результат MAX(settlement_id) ... это говорит или об утере данных о 2 сделках клиентов, или что с ct1.dc_type_id = 4 может быть только 1 клиент, или еще хз что. Но постановка/пример хотелось бы увидеть, а то как в хрустальный шар. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2017, 13:57 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответы. Поспрашивал немного насчет физического смысла запроса. По сути account_number, я так понял, идетнифицирует одного клиента банка. Client_id - это ид счета в разной валюте. две строки ( ct2.dc_type_id = 4 (transfer from) и ct2.dc_type_id = 5 (transfer to) ) фактически это операция конвертации с одной валюты в другую. Settlement_id - это фактически дата банковского дня. Соответственно строк ct2.dc_type_id = 5 , ct2.dc_type_id = 4 может быть много и не всегда между разными валютами, но всегда между разными client_id. Фактически фильтр на неравенство client_id - избыточный. Попробую сегодня сделать немного репрезентавивных тестовых данных.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2018, 11:58 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
Но фильтр на не равенство валют, актуальный: c1.balance_currency <> c2.balance_currency ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2018, 12:02 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
niv76, Можно так попробовать, если я не запутался =) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Т.к. без данных можно только прикидывать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2018, 13:45 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
MaximaXXL, надо еще дописать в конце Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ... а то может случиться ссылка ct1.dc_type_id = 4 на ct1.dc_type_id = 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2018, 14:41 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
cl_trade_id ПК транзакции. rc_cl_trade_id - ссылка на связанную парную транзакцию. Транзакции dc_type_id in (4,5) могут быль либо одиночными (если деньги заводяться или выводятся из системы). Для таких строк rc_cl_trade_id = NULL. Либо парными - когда деньги перебрасываются в системе между разными счетами (rc_cl_trade_id IS NOT NULL). Скрипт с данными в файле. Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2018, 15:12 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2018, 15:26 |
|
||
|
как хинтами добиться нужного плана
|
|||
|---|---|---|---|
|
#18+
Остался спортивный интерес сделать с группировкой и проверкой c1.balance_currency <> c2.balance_currency, не делая второго джойна ( client c2, cum_money_in_out_hist ct2 ) Похоже даже у самого получилось, может кто-то красивее может: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2018, 15:36 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39578708&tid=1884639]: |
0ms |
get settings: |
6ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
142ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 439ms |

| 0 / 0 |
