|
|
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
Задача тривиальна Нахождение количества дней в периоде когда товар присутствовал в остатках (т.е. считаем дни когда остаток товара был больше "0") Путь "в лоб" гласит о том что делаем запрос с группировкой по дням и получим там количество записей соответсвующих искомому значению Однако это очень небыстро т.к. периоды в несколько лет и товаров (комбинаций искомых) под мульён т.е. само собой напрашивается решение с использованием прямых запросов. Было бы например кво дней в продажах было бы просто т.к. даты можно выкусить из движений и сгруппировать по выкушенному а как с остатками быть ? у кого какие мысли ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 11:35 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
да... уточнение - с 7.7 воюем но в данному случае разницы нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 11:41 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
все движения в регистре делают регистраторы , как правило поэтому максимум что можно пытаться сделать это детализация до регистратора , хотя могут быть случаи когда и это хуже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 11:44 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
в том то и дело что не движения нужны эмпирически можно как-то накопительными итогами вычислить остатки из движений если брать весь период существования но ВЕСЬ период нужен только один раз - а остальное - мелкие периоды сезонности где нужно иметь остаток именно на день внутри общего периода жизни товара пс... задачка - подготовка данных для прогноза продаж и собсно обеспечения товарным запасом точек для чего необходимо знать скорость этих продаж (к-во продаж делённое на к-во дней в остатках) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 11:58 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
Имхо прямой запрос не намного ускорит дело. Все равно он должен будет для каждого товара брать остаток на начало месяца и считать по приходам/расходам для каждого дня наличие товара. Если ускорять радикально, то надо делать новую SQL таблицу или регистр какой-то, где эти данные будут храниться в явном виде. Обновляться при каждом приходе расходе. Тогда каждое проведение документа немного замедлится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 11:58 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
Alex.RuИмхо прямой запрос не намного ускорит дело. Все равно он должен будет для каждого товара брать остаток на начало месяца и считать по приходам/расходам для каждого дня наличие товара. Если ускорять радикально, то надо делать новую SQL таблицу или регистр какой-то, где эти данные будут храниться в явном виде. Обновляться при каждом приходе расходе . Тогда каждое проведение документа немного замедлится. это тригерааа мать их и объём работ по отслеживанию каждого из регистраторов могу себе представить... за неделю я не потяну такое ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 12:01 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
Какие еще тригера ? В каждом документе есть ОбработкаПроведения() , ОбработкаУдаленияПроведения(), в них и обрабатываешь. Точнее в них вставляешь глЗаполнениеЧудоТаблицы(х1,х2...) из главного модуля. Кстати в расходных накладных как правило все равно вычисляются остатки. Да и в приходных тоже. Так что объем дополнительных вычислений не большой. Преимущества SQL таблицы в том что ее можно заполнить свободно за предыдущие 100 лет. А регистр только перепроведением всех документов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 12:12 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
Тестовая таблица Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Когда разберетесь, как работает, станете гуру в получении остатков :-))) Код: 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. 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 14:08 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
огромное спасибо я никак не мог понять как мне скрестить таблицу дней с движениями теперь другой вопрос Код: plaintext 1. не попадают записи которые есть в таблице дат до первого движения в периоде левое соединение тоже не спасает... а мне чтоб просчитать полученный остаток по строкам необходим полный разворот по всем датам в периоде независимо от того когда там первая продажа была почем левое соединение не работает ?!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 18:31 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
работает левое внешнее х/з чего было огромедное спасибо тварщи !!!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2010, 18:41 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
итоговый пакет такой Код: 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. 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. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. ну и результат Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2010, 15:05 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
Last1Cmen Т.е. вам подошел вариант с INNER JOIN. Если бы потребовались все товары и все размеры с начала периода, независимо от наличия продаж, пришлось бы таблицу дат еще 2 раза соединить CROSS JOIN с таблицами товаров и размеров, а потом LEFT JOIN с таблицей продаж. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2010, 10:05 |
|
||
|
SQL-щики нид хелп по вопросу количества дней в остатках
|
|||
|---|---|---|---|
|
#18+
HoBTID Last1Cmen Т.е. вам подошел вариант с INNER JOIN. Если бы потребовались все товары и все размеры с начала периода, независимо от наличия продаж, пришлось бы таблицу дат еще 2 раза соединить CROSS JOIN с таблицами товаров и размеров, а потом LEFT JOIN с таблицей продаж. это как раз было бы легче т.к. 1це цельные периоды ворочает шустро а вот с такими хитрыми подвывертами есть проблемы по скорости этот запрос отрабатывает без кэша (первый раз) порядка 3-5 минут а вот стандартный приблизительного объёма обрабатываемых записей почти в несколько раз дольше и приходилось делать через предварительный расчет ночью и потом уже по результирующему справочнику строить сам отчет да... если кто вздумает таким образом и остатки получать то не советую, для этого подойдёт более приемлимый метод "остаток на период + движения по смещению даты внутри следующего периода" Код: 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. это без флага в регистре "быстрая обработка движений" с ним можно без таблицы журнала работать напрямую с таблицей движений регистра ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2010, 10:51 |
|
||
|
|

start [/forum/topic.php?fid=28&tid=1522402]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
176ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 249ms |
| total: | 522ms |

| 0 / 0 |
