|
|
|
Нужно решить проблему динамического складского учёта
|
|||
|---|---|---|---|
|
#18+
На данный момент учёт в БД динамический, то есть что бы посчитать количество на складе, в представлении для каждой позиции отнимается от всех поступлений все продажи. Сейчас база данный очень растолстела и эта операция занимает каждый раз по 2-5 секунды. Нужно как-то опитимизировать это безобразие. Скорее всего мне нужно сделать отдельную таблицу для статического учёта. Но вот одна проблема. Дело в том что есть главная таблца со всеми товарами куда постоянно добавляются каждую неделю новые позиции. Если будет вторая таблица с учётом то тогда она мало того-что она должна дублировать таблицу с товарами, так она ещё и должна вести учёт по нескольким складам. Выкладываю Create таблицы с товарами. Код: 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. 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. Есть идея как сделать учёт: 1) Создать таблицу типа ID ProductID Count StoreID1 1 256 11 1 423 2 Получается, что для каждого склада своя позиция, что увеличивает количество записей пропорционально складам. 2) Другая таблица типа ID ProductID Store1 Store21 1 256 213 Тут уже меньше записей, но больше колонок. Больше идей нет. Более того у меня один важный вопрос, нужно ли делать отдельную таблицу для этого или можно прям в таблице с товарами это сделать. Дело втом, что я не знаю как синхронизировать эти таблицы, что бы когда новые позиции добавлялись, то они появлялись во всех позициях. Единственный вариант который я знаю, это программно через тригеры на INSERT. Подскажаите пожалуйста как реализовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2014, 14:28 |
|
||
|
Нужно решить проблему динамического складского учёта
|
|||
|---|---|---|---|
|
#18+
Kimelу меня один важный вопрос, нужно ли делать отдельную таблицу для этого или можно прям в таблице с товарами это сделать. Дело втом, что я не знаю как синхронизировать эти таблицы, что бы когда новые позиции добавлялись, то они появлялись во всех позициях. Отдельная таблица - нужна. Выйграешь на блокировках. Синхронизировать таблицы при добавлении новых товарных позиций - не нужно. Заводи остаток при первом его движении. MERGE в триггерах тебе в руки. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2014, 14:33 |
|
||
|
Нужно решить проблему динамического складского учёта
|
|||
|---|---|---|---|
|
#18+
Основы проектирования складской БД (v. 2) Велосипедов такого типа - легион. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2014, 10:55 |
|
||
|
Нужно решить проблему динамического складского учёта
|
|||
|---|---|---|---|
|
#18+
Kimel, Можно попробовать обойтись без дополнительной таблицы: 1. В главную таблицу добавить три поля (Приход, Расход, Остаток) 2. По каждому товару главной таблицы прописать Приход - как сумму всех приходов. 3. По каждому товару главной таблицы прописать Расход - как сумму всех расходов. 4. По каждому товару главной таблицы прописать Остаток - как разницу в ней между Приходом и Расходом. После этой манипуляции появляются возможности: 1. Взять количество остатка товара прямо из главной таблицы без пересчета. 2. Периодически бороться с пухлостью базы (сохраняя предварительно действующую в архив для просмотра) при необходимости (рано или поздно это нужно делать): - удаляем приходы за прошлый год (например) уменьшая на соответствующее значение Приходы главной таблицы - Удаляем продажи за прошлый год (например) уменьшая на соответствующее значение Расходы главной таблицы - по новой вычисляем Остатки как разницу между Приходом и Расходом в главной таблице - сжимаем рабочую базу данных. Тонкости: 1. Соответственно при приходе дополнительно увеличиваем Приход и Остаток товара в главной таблице на кол-во прихода. 2. Соответственно при продаже дополнительно увеличиваем Продажу и уменьшаем Остаток товара в главной таблице на кол-во прихода. 3. Общий остаток за предприятие будете брать из главной таблицы, а по складам - старым способом. Примечание: 1. Задача не совсем простая и требует большего ума чем просто положить приход в приход а продажу в продажу. 2. Нужна доработка действующих алгоритмов прихода и продажи. 3. Возможно Нужны дополнительные режимы для контроля прихода, расхода и перерасчета остатков в главной таблице в соответствии с выбранной политикой товаро учета. 4. Возможны другие трудности вытекающие из предложенного алгоритма, я не знаю схемы вашей БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2014, 19:01 |
|
||
|
Нужно решить проблему динамического складского учёта
|
|||
|---|---|---|---|
|
#18+
Kimel, + как вариант (при наличии кучи складов) все таки создать доп таблицу и привязать ее к главной таблице к коду товара с тем же подходом, но уже по складам: -Код главной таблицы -код склада -приход -расход -остаток то есть приход, расход и остаток не в главной таблице а в подчиненной. НО ЭТО БУДЕТ ЕЩЕ СЛОЖНЕЕ !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2014, 19:14 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=30&tid=1540915]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 253ms |
| total: | 385ms |

| 0 / 0 |

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