|
|
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
Задача: посчитать перераспределение премии по сотрудникам, так как его никто не считал на каждого, а вносили общую сумму на всех. Что сделано: первое поколение считаю так: Код: plsql 1. 2. Сама премия распределяется всегда в одинаковых пропорциях на каждого сотрудника, то есть, если из 100 рублей сотрудник получил 10, то из 50 он получит 5, если количество сотрудников не изменилось. Но при добавлении в проект нового сотрудника, его коэффициент может отличаться от других. второе и последующие поколения считаю так: Код: plsql 1. То есть, распределяю пропорционально. Но возникла ситуация, когда количество сотрудников уменьшилась, а премия не изменилась. Для правильного распределения необходимо посчитать вес премии сотрудника из прошлого поколения, без учета тех премий, которые в новом поколении отсутствуют, но сделать это не получается. Попытка сделать sum (nvl2 (premium_obj[cv(), cv ()]), premium_obj[cv()-1, cv ()], 0)[cv()-1, cv ()] или как-нибудь так провалилась. Не позволяет модель двойную адресацию делать. Посчитать ratio_to_report также нет возможности, так как возникает ошибка 30483. Подскажите пожалуйста, как можно посчитать в модели сумму по прошлому поколению, используя данные из текущего поколения. Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2016, 12:31:34 |
|
||
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
Постановку задачи по SQL всегда нужно начинать с описания и примера входных данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2016, 12:55:34 |
|
||
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
Перечень печенья в печени, В дополнение к ответу на вопрос выше еще не мешало бы уточнить откуда навязчивое желание натянуть модель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2016, 12:59:05 |
|
||
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
Модель натянуть захотелось потому, что LAG\LEAD не справляется, нужен пересчет всех поколений, а их там бывает до 20 по некоторым проектам. данные OBJECTDDATEPKPREMIUMPERSON_ID103.09.201662000001103.09.201662000002103.09.201662000003103.09.201662000004103.09.201662000005103.09.201662000006103.09.201662000007103.09.201662000008104.09.2016620000010102.09.201652000001102.09.201652000002102.09.201652000003102.09.201652000004102.09.201652000005102.09.201652000006102.09.201652000007102.09.201652000008102.09.201652000009102.09.2016520000010101.09.201642500001101.09.201642500002101.09.201642500003101.09.201642500004101.09.201642500005101.09.201642500006101.09.201642500007101.09.201642500008101.09.201642500009101.09.2016425000010131.08.201632500001131.08.201632500002131.08.201632500003131.08.201632500004131.08.201632500005131.08.201632500006131.08.201632500007131.08.201632500008131.08.201632500009131.08.2016325000010130.08.201622000001130.08.201622000002130.08.201622000003130.08.201622000004130.08.201622000005130.08.201622000006130.08.201622000007130.08.201622000008130.08.201622000009127.08.201612000001127.08.201612000002127.08.201612000003127.08.201612000004127.08.201612000005127.08.201612000006127.08.201612000007127.08.201612000008127.08.201612000009 В результате надо получить в первом поколенее premium_obj = premium/9. В третьем надо у первых 9 работников оставать премию как есть, а новому посчитать 50000. 5-е поколение надо расчитать так, чтобы 50000, вычтенных из премии, распределились по объектам, сохраняя при этом коэффициенты. То есть, должно получиться что-то вроде 17777.(7) у 9 работников и 40000 у оставшегося. 6-е поколение надо рассчитать так, чтобы разница в суммах перераспределилась пропорционально. И вот этот как раз момент у меня не получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2016, 13:29:44 |
|
||
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
Ой... Даты немного поплыли при запихивании их в таблицу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2016, 13:31:47 |
|
||
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
Перечень печенья в печениОй... Даты немного поплыли при запихивании их в таблицу...Нахрена вообще указывать атрибуты, которые не имеют никакого отношения к задаче? Лучше б ты привел то, что надо и в формате with. Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. Интересно было бы попробовать решить с помощью recursive subquery factoring, хотя есть подозрение, что из-за множества ограничений на рекурсивный член, не взлетит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 01:24:59 |
|
||
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopИнтересно было бы попробовать решить с помощью recursive subquery factoring, хотя есть подозрение, что из-за множества ограничений на рекурсивный член, не взлетит.Взлетело. Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. В обоих решениях предполагается, что на конкретной итерации не могут одновременно добавляться и удаляться persons. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 01:57:11 |
|
||
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
Спасибо большое за ответы. Кажется, получилось оба варианта прикрутить, правда, немного допилить пришлось. Успехов вам и хорошего вечера (если у вас вечер). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2016, 17:28:16 |
|
||
|
MODEL, ratio_to_report, нужна помощь
|
|||
|---|---|---|---|
|
#18+
Перечень печенья в печени, Во втором случае вместо лишнего соединения в t просится join partition by pk, premium. Для тюнинга, имело бы смысл аналитику (count) предварительно посчитать и, возможно, использовать временную таблицу с индексом по pk если много данных и высокая кардинальность по pk. Модель тоже можно несколько улучшить, но оба решения сильно уступают PL/SQL как по производительности так и по масштабируемости. Разве что текста меньше. Так что запросы были опубликованы больше для демонстрации возможностей инструмента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2016, 00:12:55 |
|
||
|
|

start [/forum/topic.php?fid=52&gotonew=1&tid=1887503]: |
0ms |
get settings: |
8ms |
get forum list: |
21ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
214ms |
get topic data: |
12ms |
get first new msg: |
6ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 568ms |

| 0 / 0 |
