|
|
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
VladShНа КТС-е стоимостью в несколько лимонов баксов очень даже легко. Причем в базу ежедневно добавляется несколько десятков млн строк. Мать! Опять рекламные лозунги. Значит когда вы зявляли, что задача решается "легко", вы всегд лишь "забыли" добавить про "КТС стоимостью в несколько лимонов баксов"? Я правильно вас понял? Вот ваш ответ: Нужно построить систему, которая будет показывать остатки товара в реальном времени... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2005, 20:15 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Итак, возвращаясь к исходному вопросу: человека волнует как получать текущие остатки достаточно быстро. Автор использовал термин "в реальном времени", но на самом деле имелось в виду достаточно оперативно, в течении 5-10 минут максимум. Автор не использовал термин OLTP-системы, но подразумевались именно они. Итак, неужели эта задача решается легко? А если нелегко, то какие способы решения, уважаемые участники, вы видите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2005, 20:18 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Мать! Опять рекламные лозунги. Mazzy! Вы спросили: И вы хотите сказать, что суммирование всех записей дает приемлимый результат и при огромных размерах баз? Я Вам ответил: На КТС-е стоимостью в несколько лимонов баксов очень даже легко. Причем в базу ежедневно добавляется несколько десятков млн строк. Причем здесь реклама, если такой КТС в Москве никто не купит? Их от силы 2-3 (по-моему, все в АФК Система). Автор использовал термин "в реальном времени", но на самом деле имелось в виду достаточно оперативно, в течении 5-10 минут максимум. Автор не использовал термин OLTP-системы, но подразумевались именно они. Именно транзакционные системы (OLTP). Еще раз повторю: время расчета остатка значительно меньше 0,1 сек. Пример примитивный: за год имеем 10 млн строк в таблице движения товара. Пусть в фирме (корпорации, группе фирм) 10 складов и номенклатура 50 тыс. позиций. С учетом того, что число строк по разным позициям товара и складам далеко не одинаково, для расчета среднестатистической производительности примем, что ходовых 5 складов и 10 тыс. позиций товара. Тогда для расчета остатка товара надо просмотреть: 10.000.000 : 10.000 позиций : 5 складов = 200 строк. Сколько времени серверу потребуется для выборки по индексам 200 строк и их суммирования? Максимум 0,0001 секунд. Итак, неужели эта задача решается легко? Легко. -- Шумов В. http://www.acdplus.ru/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2005, 21:17 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Значит когда вы зявляли, что задача решается "легко", вы всегд лишь "забыли" добавить про "КТС стоимостью в несколько лимонов баксов"? Я правильно вас понял? Неправильно! Названный КТС используется в биллинге для работы со сверхбольшими БД. К складам это никакого отношения не имеет. Об этом было упомянуто именно (и только) в связи с быстрым обсчетом сумм на очень больших объемах. Кстати, если взять крупную торговую (производственную) контору, то тот же SAP R3 там работает на железе ну никак не дешевле 300 килобаксов. Причем остатки в реале не считает))) Если кого-то ввел в заблуждение, извините! Не по умыслу. -- Шумов В. http://www.acdplus.ru/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2005, 21:27 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
mazzyИтак, возвращаясь к исходному вопросу: человека волнует как получать текущие остатки достаточно быстро. Автор использовал термин "в реальном времени", но на самом деле имелось в виду достаточно оперативно, в течении 5-10 минут максимум. Автор не использовал термин OLTP-системы, но подразумевались именно они. Итак, неужели эта задача решается легко? А если нелегко, то какие способы решения, уважаемые участники, вы видите? Вот это - в течение 5-10 минут звучит очень прикольно для OLTP системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 09:56 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Учетные системы Ltd.вычисление зависимостей при проведении документов “задним числом” Очень вот это интересно. Как оно у вас происходит при иерархической комплектации с достаточно глубокой иерархией при том, что товар еще перемещается по разным складам. Достаточно поменять задним числом цену прихода хотя бы одного комплектующего как количество цепочек разрастается просто немеренно. Одних изделий получается порядка сотни. И все это нужно перепровести. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 10:24 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Сколько времени серверу потребуется для выборки по индексам 200 строк и их суммирования? Максимум 0,0001 секунд.Минуточку ! Про какие остатки идёт речь ? Для одного товара ? Для всей номенклатуры ? Также надо сразу поднимать вопрос: За какой период следует хранить движение товара? Само собой понятно, что история за 2недели и за 5лет это две большие разницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 10:24 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Crip Учетные системы Ltd.вычисление зависимостей при проведении документов “задним числом” Очень вот это интересно. Как оно у вас происходит при иерархической комплектации с достаточно глубокой иерархией при том, что товар еще перемещается по разным складам. Достаточно поменять задним числом цену прихода хотя бы одного комплектующего как количество цепочек разрастается просто немеренно. Одних изделий получается порядка сотни. И все это нужно перепровести. Ну и что? Каждая запись при приходе снабжается уникальным идентификатором, которая тащится по всем документам. При изменении цены пересчитываются проводочные части всех документов (исключая/не исключая проводки по внутренним перемещениям) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 10:29 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
gardenman mazzyИтак, возвращаясь к исходному вопросу: человека волнует как получать текущие остатки достаточно быстро. Автор использовал термин "в реальном времени", но на самом деле имелось в виду достаточно оперативно, в течении 5-10 минут максимум. Автор не использовал термин OLTP-системы, но подразумевались именно они. Итак, неужели эта задача решается легко? А если нелегко, то какие способы решения, уважаемые участники, вы видите? Вот это - в течение 5-10 минут звучит очень прикольно для OLTP системы. Именно. Но так был сформулирован исходный вопрос. Вернее, в исходном вопросе вообще говорилось о реальном времени :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 11:39 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Так как? Есть идеи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 13:44 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Остаток - это количество. Количество - абстрактная величина не привязанная к цене. Сумма=коичество*остаток. => Храните количество и будет вам сумма. Если уж очень накладно хранить остатки на каждый день, то храните хотябы дневные обороты (в количестве). В году всего 365 дней. За десять лет это всего 3650 записей. Сбить + и - за десять лет по дневным оборотам - раз плюнуть (для одного товара) и помножайте на цену. Если цена меняется во времени, то (это фича, которую я использовал для быстрого вычисления курсовой разницы) храните ее в развернутом виде по дням. Для чего следует добавить еще пару таблиц и несколько триггеров для наполнения. А потом левым джойном количество к ценам, левым джойном их!!! ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 14:19 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
gardenman... Если уж очень накладно хранить остатки на каждый день, то храните хотябы дневные обороты (в количестве). В году всего 365 дней. За десять лет это всего 3650 записей. Сбить + и - за десять лет по дневным оборотам - раз плюнуть (для одного товара) и помножайте на цену. ... Остатки могут быть по складам, местам хранения, материально-ответственным лицам, б.счетам, ... Так что "За десять лет всего 3650 записей" - это блеф ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 15:56 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
panchУ меня средний такой оптовый склад пищевых продуктов. В упаковках , весовые и в литрах(не бензин). Иногда портятся(прокисают). Приходится списывать. Среднему покупателю надо самые несвежие продукты. Випу - свежак только. Отпуск и прием идет фурами. По складу шныряют несколько погрузчиков. Для их проезда оставляют пути. Проблема расставить все так при разгрузке прихода чтобы не забыть где оно лежит. наименований товара тысяч пять. Ежедневный оборот - до 50 фур. Оперативные остатки нужны на данный момент (конечно по степени устаревания). Идет учет товаров в пути. Возможно резервирование товара который еще не доехал(!) Процесс автоматизации в самом начале. Нет ли готового подобного решения . SAP R/3 :) 1 текущие остатки 2 разные, скажем так, виды запасов, в частности блокированный 3 резервирование реализуется как учет потребностей. в частности, имеется возможность резервировать на будущее (посмотрите http://help.sap.com/saphelp_46c/helpdata/ru/93/744b8a546011d1a7020000e829fd11/frameset.htm) 4 Система управления складами (СУС) позволяет управлять по местам хранения. посмотрите http://help.sap.com/saphelp_46c/helpdata/ru/c6/f85c504afa11d182b90000e829fbfe/frameset.htm Вопросы производительности 1 Остатки, доступность по материалам на текущий момент - не проблема, мгновенно 2 На заданную дату - получается как остаток на опред. (ближайший к заданной дате) период (хранится в системе, обновляется при каждом движении) + сумма движений за оставшиеся дни. Не фонтан, но вполне терпимо - до 1 мин. Да, и olap по остаткам еще никто не отменял :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 16:54 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
7654 gardenman... Если уж очень накладно хранить остатки на каждый день, то храните хотябы дневные обороты (в количестве). В году всего 365 дней. За десять лет это всего 3650 записей. Сбить + и - за десять лет по дневным оборотам - раз плюнуть (для одного товара) и помножайте на цену. ... Остатки могут быть по складам, местам хранения, материально-ответственным лицам, б.счетам, ... Так что "За десять лет всего 3650 записей" - это блеф А вы сначала определитесь, что вам надо - остаток по конкретному товару (партии) или еще как? как мне видится вот тут: "складам, местам хранения, материально-ответственным лицам,..." - вы все в кучу перемешали. И еще одно маленькое замечание. Движение остатков происходит далеко не каждый день и не по всем товарам (по крайней мере в субботу-воскресенье обычно не двигаются). поэтому цифру 3650 - я ну очень сильно преувеличил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 17:36 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
2 AnS1 На заданную дату - получается как остаток на опред. (ближайший к заданной дате) период (хранится в системе, обновляется при каждом движении) + сумма движений за оставшиеся дни - это вы в точку. Правда в таком случае необходима процедура закрытия (формирования остатков) на дату. Да и обычно текущий остаток всегда есть в системе. Можно от него вглубь считать. Короче - проектирование это 90% производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2005, 17:39 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
gardenman2 AnS1 На заданную дату - получается как остаток на опред. (ближайший к заданной дате) период (хранится в системе, обновляется при каждом движении) + сумма движений за оставшиеся дни - это вы в точку. Правда в таком случае необходима процедура закрытия (формирования остатков) на дату. Да и обычно текущий остаток всегда есть в системе. Можно от него вглубь считать. Короче - проектирование это 90% производительности. в R/3 процедуры закрытия остатков на дату не нужно. Каждое движение материала на дату проводки обновляет остаток по периоду указанной даты. Такой вот регистр :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 10:01 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
AnS1 gardenman2 AnS1 На заданную дату - получается как остаток на опред. (ближайший к заданной дате) период (хранится в системе, обновляется при каждом движении) + сумма движений за оставшиеся дни - это вы в точку. Правда в таком случае необходима процедура закрытия (формирования остатков) на дату. Да и обычно текущий остаток всегда есть в системе. Можно от него вглубь считать. Короче - проектирование это 90% производительности. в R/3 процедуры закрытия остатков на дату не нужно. Каждое движение материала на дату проводки обновляет остаток по периоду указанной даты. Такой вот регистр :) Ну...) не знаю насколько это эффективно. В разных случаях по разному. Для некоторых возможно лучше хранить только обороты. Иногда обороты и остатки. Иногда остатки стоит формировать отдельной процедурой. Но факт остается фактом - процедура формирования (коррекции остатков) в R/3 существует. Я ,например, в своей системе (банк) использовал остаток еще с одной целью - как граница закрытого периода. И правильно - там баланс подбивают каждый рабочий день. А на предприятиях - где баланс делают раз в квартал и практикуются проводки задним числом - можно было бы хранить только обороты. Но велика вероятность при проводке задним числом получить где-нить в будущем черное или красное сальдо. Спасёт лишь то, что базы данных у предприятий как правило крохотные. потому, что в баланс идут только комулятивные проводки. Типа - расчет зарплаты - это отдельная подсистема обрабатывающая несколько тысяч человек. А в балансе это всего лишь пара десятков проводок. А править остатки задним числом - это значит иметь длинную транзакцию. Не для всех ОЛТП систем это приемлемо. Поэтому и делают процедуры отката/наката проводок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 10:24 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
gardenman Ну...) не знаю насколько это эффективно. В разных случаях по разному. Для некоторых возможно лучше хранить только обороты. Иногда обороты и остатки. Иногда остатки стоит формировать отдельной процедурой. Но факт остается фактом - процедура формирования (коррекции остатков) в R/3 существует. Я ,например,... Так, ближе к теме. Вопрос был "Нужно построить систему, которая будет показывать остатки товара в реальном времени" Есть что сказать по заданному вопросу? Если нет, но сказать что-нибудь хочется - открывайте новую тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 15:26 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов Crip Учетные системы Ltd.вычисление зависимостей при проведении документов “задним числом” Очень вот это интересно. Как оно у вас происходит при иерархической комплектации с достаточно глубокой иерархией при том, что товар еще перемещается по разным складам. Достаточно поменять задним числом цену прихода хотя бы одного комплектующего как количество цепочек разрастается просто немеренно. Одних изделий получается порядка сотни. И все это нужно перепровести. Ну и что? Каждая запись при приходе снабжается уникальным идентификатором, которая тащится по всем документам. При изменении цены пересчитываются проводочные части всех документов (исключая/не исключая проводки по внутренним перемещениям) Вы хоть представляете о чем говорите? В случае комплектация-разукомплектации 1 строчка расхода может определяться кучей записей прихода и других операций комплектации-разукомплектации. Ссылочка на запись прихода конечно протягивается, но при этом все равно образуется иерархическая цепочка раскрутка которой задача совсем не тривиальная и не быстрая. Поэтому и спрашиваю. Конечно в случае простого склада все элементарно и главное быстро, но производственные операции "совсем другая тема". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 11:50 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Во первых, мы говорили о складе. Во вторых, разузловывать на ходу не объязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 12:48 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
2Сахават Юсифов Ну вообщем то сборочно-разборочные операции должны присутствовать в нормальной складской программе. Что вы понимаете под разузловывать и почему не обязательно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 13:24 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Потому что изменение цены не влияет на количество отпущенного материала. Это информация уже находится в системе, нужно только переоценить факт и сообщит. А остальное при формировании запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 16:00 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовПотому что изменение цены не влияет на количество отпущенного материала. Это информация уже находится в системе, нужно только переоценить факт и сообщит. А остальное при формировании запросов. Если с точки зрения чистых товарных остатков, то конечно никаких проблем нет, так как меняется остаток только конкретного товара. Единственное это контроль промежуточного минуса, но это тоже небольшая проблемка. А вот если у вас считаются остатки в учетных (закупочных) ценах, то тут уже совсем другой коленкор. В принципе уже всё обсудили и выводы сделаны еще на первой странице. Просто тут рекламируют некую систему, как я подозреваю с функционалом более ограниченным, чем заявляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 16:23 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Crip Учетные системы Ltd.вычисление зависимостей при проведении документов “задним числом” Очень вот это интересно. Как оно у вас происходит при иерархической комплектации с достаточно глубокой иерархией при том, что товар еще перемещается по разным складам. Достаточно поменять задним числом цену прихода хотя бы одного комплектующего как количество цепочек разрастается просто немеренно. Одних изделий получается порядка сотни. И все это нужно перепровести. На наш взгляд понятие "комплектация" характерно для задач учета товаров (напрмер машина с кондиционером, полным электропакетом, металик). Но для товаров иеирархия комплектации как-правило не характерна - покупатель просто не поймет сложной системы вложенных опций. Для производства более подходит понятие технологическая карта калькуляции, причем вложенность(рекурсия) таких карт соответствует количеству переделов производства (не путать с общим количеством полуфабрикатов собствнного производства). Как правило, количество переделов на предприятии не превышает 1-го порядка (мы сталкивались до 5 переделов включая изготовление разовой остнастки и приемку по качеству) Полуфабрикаты, вышедшие из передела представляют собой готовое неразделимое изделие с обственным учетным артиклом. Алгоритм вычисления зависимостей при проведении "задним числом" нашей системы учитавает влияние измененной записи о ТМЦ как непосредственно, так и по картам калькуляции, куда данная ТМЦ входит согласно технологического процесса, причем с учетом рекурсии (переделов) Вычисление зависимостей "задним числом" действительно очень сложная вещь. Однако, поскольку без возможности проведения "задним числом" система в принципе не пригодна для динамического планирования (для будующих плановых событий сегодняшняя дата всегда "заднее число"), а пересчет всех документов от даты внесенных изменений очень длительное процедура, эти зависимости приходится вычислять. При этом мы стараемся вычислять зависимости так, как это делал бы обычный бухгалтер со счетами - он, то за задачей справлся, когда компьютеров еще не было. Наиболее же сложной проблемой является вычисление зависимостей при автоматическом сопоставлении плановых документов с фактическими, да еще и учетом изменения курсов валют, если плановые документы выражены в одной валюте, а фактические в другой... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2005, 19:47 |
|
||
|
Нужно построить систему, которая будет показывать остатки товара в реальном времени...
|
|||
|---|---|---|---|
|
#18+
Та-ак. Опять ушли в сторону. Уважаемые участники, если хочется обсудить другой вопрос, открывайте новую ветку. Итак, вернемся к исходному вопросу? Нужно построить систему, которая будет показывать остатки товара в реальном времени.. было перечислены три варианта: 1. физическое разделение периодов на разные таблицы 2. суммирование "от начала времен" 3. суммирование "от конца" Других предложений нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2005, 10:21 |
|
||
|
|

start [/forum/topic.php?fid=29&msg=33310189&tid=1528358]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
26ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 193ms |
| total: | 285ms |

| 0 / 0 |
