|
|
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
больше интересует каким образом лучше выбирать остатки на складе.. у меня 2 варианта..это обычное sum(приход-расход) по всей базе(но я не знаю на сколько это повлияет на скорость при большом количестве записей) или создавать по закрытию месяца таблицу остатков поделитесь опытом в организации склада плиз ПС база ms sql 2005/2008 (еще не знаю какая версия стоит на сервере) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2011, 22:24 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
ther, В супермаркете тысячи товарных позиций, тысячи продаж в день. При этом остатки по тому или иному товару запрашиваются тоже тысячи раз в день и при просмотре, и в различных отчетах, и в расчетах при планировании. При этом, при закрытии месяца производится инвентаризация. Т.е. сверка остатков по документам с реальными остатками. Т.е. ежемесячная агрегация остатков - это даже не вспомогательный документ для оптимизации запросов, а (обычно) неотьемлимая часть учета. И диаметрально противоположный вариант. Есть склад какой-то "Рога и копыта" с сотней сделок в месяц и сотней позиций на складе. Инвентаризация делается чисто для проформы, если делается. А остатки можно считать по базе и нагрузкой назвать это тяжело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2011, 23:06 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Как вариант - хранить текущие остатки, остатки на начало периода, операции движения за период и резервы. Тогда находить текущий остаток и создавать резервы можно будет одним, двумя легкими запросами. Промежуточные остатки- запросом за период - сумма остатков на начало периода и движение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 02:01 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
ther, Во многих системах учета банально вводят таблицу текущих остатков, чтобы вообще ничего не суммировать. При большой частоте продаж - это разумно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 02:37 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
ммм... предлагаю хранить остатки на конец каждого периода (месяца, как пример) и текущие остатки - как например с периодом 01.01.3001 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 11:23 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
спасибо..так и сделаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 13:25 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Edd.DragonВо многих системах учета банально вводят таблицу текущих остатков, чтобы вообще ничего не суммировать. При большой частоте продаж - это разумно. Но при этом приходится разруливать update conflict-ы или громоздить бесконфликтную схему. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 15:33 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovEdd.DragonВо многих системах учета банально вводят таблицу текущих остатков, чтобы вообще ничего не суммировать. При большой частоте продаж - это разумно. Но при этом приходится разруливать update conflict-ы или громоздить бесконфликтную схему. ТС, любой из предложенных вариантов для корректной реализации (без ошибок системы или алгоритмических ошибок) требует хорошего понимания того, как пользователи в программе одновременно будут выбирать остатки и изменять их. Не забудь предусмотреть корректную реакцию системы при попытке отгрузить товара больше чем есть. Если выберешь вариант с остатками (скорее всего, и это правильно :) ) и реализуешь алгоритмы: - оприходуй энное количество разного товара - запусти параллельно несколько автоматических тестовых процессов по отгрузке/поставке на склад, и несколько процессов, просто получающих остатки. Приветствуется в каждом из процессов оприходование или отгрузка большого перечня товаров одним "пакетом" (как в реальной жизни по одной накладной кучу товара). Тщательно проверь: 0) exception'ы. 1) что хранится в итоге в остатках, и что должно было получиться. 2) сколько времени требуется на получение остатков (min, max, avg) 3) сколько времени требуется на изменение остатков (min, max, avg) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 16:10 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
АнатоЛойЕсли выберешь вариант с остатками (скорее всего, и это правильно :) ) и реализуешь алгоритмы: Сорри: вышесказанное не зависит от выбранного решения - протестируй таким образом в любом случае :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 16:12 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovEdd.DragonВо многих системах учета банально вводят таблицу текущих остатков, чтобы вообще ничего не суммировать. При большой частоте продаж - это разумно. Но при этом приходится разруливать update conflict-ы или громоздить бесконфликтную схему. Тут уж что дешевле. Громоздить схему или пересчитывать постоянно. Обычно хватало локать запись на апдейт при проведении. А зазевавшемуся менеджеру, который с утра открыл документ продажи и ввел продажу имеющегося товара, а вечером только его провел, когда товар уже ушел - сообщать о том, что он тормоз )) Хотя может были еще ньюансы, о которых я уже давно позабыл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 20:43 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Edd.DragonОбычно хватало локать запись на апдейт при проведении Ну, это пройдёт на Оракуле с его бесконечным ожиданием конкурирующих транзакций. В остальных случаях - "тщатильнее надо". Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 20:51 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovEdd.DragonВо многих системах учета банально вводят таблицу текущих остатков, чтобы вообще ничего не суммировать. При большой частоте продаж - это разумно. Но при этом приходится разруливать update conflict-ы или громоздить бесконфликтную схему. ожидания на системных блокировках сводятся на нет использованием коротких системных транзакций. программирование в стиле WEB интерфейса само по себе диктует применение коротких транзакций в рамках одного http запроса. одна бизнес-операция должна разбиваться на несколько системных транзакций. состояние бизнес-операции хранится в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2011, 23:50 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovEdd.DragonОбычно хватало локать запись на апдейт при проведении Ну, это пройдёт на Оракуле с его бесконечным ожиданием конкурирующих транзакций. В остальных случаях - "тщатильнее надо". Э-э-э, это в смысле, например, при обновлении записи ждать бесконечно долго, пока она не освободится после окончания конкурирующей транзакции? В Informix я тоже так умею: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2011, 02:03 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
ther, таблицы: накладные остатки на каждый день текущие остатки каждый день в 00:00 закрываемся, копируем текущие остатки в остатки накаждый день. Все. каждая операция изменяет только текущие остатки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2011, 16:26 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Озверин каждый день в 00:00 закрываемся, копируем текущие остатки в остатки накаждый день. Все. каждая операция изменяет только текущие остатки. Что делать, если нашли под столом неучтенную позавчерашнюю накладную? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2011, 18:45 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
перещитать вчерашние остатки само собой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2011, 19:08 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Ivan Durak, а если накладная месячной давности? пересчитываем весь месяц ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2012, 22:06 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
OLEG_ZHа если накладная месячной давности? пересчитываем весь месяц ? А в чём проблема проапдейтить 30 записей?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2012, 22:42 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovOLEG_ZHа если накладная месячной давности? пересчитываем весь месяц ? А в чём проблема проапдейтить 30 записей?.. Собственно, я лишь хотел обратить внимание на алгоритмическую несостоятельность следующей фразы: Озверинкаждая операция изменяет только текущие остатки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 11:59 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovEdd.DragonВо многих системах учета банально вводят таблицу текущих остатков, чтобы вообще ничего не суммировать. При большой частоте продаж - это разумно. Но при этом приходится разруливать update conflict-ы или громоздить бесконфликтную схему. Извиняйте, что поднимаю затухшую тему. Стало интересно: кто-нибудь реализовывал на практике бесконфликтную схему коррекции СКЛАДСКИХ остатков (т.е. тех, которые должны всегда соблюдать check (qty>=0) - в отличие от сальдо контрагентов) ? Dimitry Sibiryakov показывал схему , при которой вместо апдейтов идут инсерты, а планировщиком периодически выполняется "схлопывание" строк по ключу типа contragent_id. Как приспособить это к складу изделий, в котором остатки всегда должны быть >= 0 ? У мну есть подозрение , что это можно сделать через deferred constraint\'ы, но серьёзной проверки я не делал. ЗЫ. Здесь я ответа на этот же вопрос так и не получил. Посоветовали ваять оптимальный код и проч. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 08:18 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
ТаблоидКак приспособить это к складу изделий, в котором остатки всегда должны быть >= 0 ? Я не реализовывал, но принципиальных проблем не вижу. Я сделал бы materialized view, в котором схлопываются суммы (то есть собственно считаются текущие остатки), и повесил бы на него constraint или исключение, удерживающее остаток неотрицательным. Refresh fast on commit и дело в шляпе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 09:15 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
softwarerЯ сделал бы materialized view, в котором схлопываются суммы (то есть собственно считаются текущие остатки), и повесил бы на него constraint или исключение, удерживающее остаток неотрицательным. Refresh fast on commit и дело в шляпе.Это слишком лёгкий путь :-) Что делать тем, у кого СУБД не имеет такой волшебности, как матвью ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 11:02 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
ТаблоидСтало интересно: кто-нибудь реализовывал на практике бесконфликтную схему коррекции СКЛАДСКИХ остатков? Как приспособить это к складу изделий, в котором остатки всегда должны быть >= 0 ? Всё, что упоминалось как решения, есть решения на конкретных СУБД. Решение будет зависеть от возможностей СУБД. Тебе нужно под конкретную СУБД? Или нужно общее решение, которое можно реализовать на конкретном перечне СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 13:52 |
|
||
|
подскажите метод организации склада
|
|||
|---|---|---|---|
|
#18+
ТаблоидЧто делать тем, у кого СУБД не имеет такой волшебности, как матвью ? Разруливать update conflict-ы, если в конкретной СУБД они порождаются. А лучше - брать СУБД, где их нет. Например - Оракул. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 14:08 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=40&tid=1541344]: |
0ms |
get settings: |
5ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 210ms |
| total: | 346ms |

| 0 / 0 |
