|
|
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
Добрый день, разрабатываю базу данных на MS SQL . Есть таблица Шапка документа Номер, Дата, Товар, Поставщик, Сумма Документа. И тело документа связанное по «товару» из шапки Наименование, Партия, Количество, Цена, Сумма, Вопрос как правильно организовывать остатки в БД Пока крутятся несколько способов 1. считать на ходу подбивать приходы – расходы есть текущий остаток. Способ хороший но если база хорошо вырастит то это будет не быстро. 2. Способ создать таблиц которая в конце каждого дня будет иметь остаток Имеем + по скорости но если документ поменяют задним числом то нужно от этого числа пересчитывать эту таблицу 3. Способ иметь простую таблицу без даты в которую при приходе просто будет Плюсоваться или отнимется количество + не нужно пересчитывать таблицу - Имеем только последние остатки а не на определенную дату. Как правильно организовать остатки какие есть еще решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2008, 18:49 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
ZenForeverДобрый день, разрабатываю базу данных на MS SQL . Есть таблица Шапка документа Номер, Дата, Товар, Поставщик, Сумма Документа. И тело документа связанное по «товару» из шапки Наименование, Партия, Количество, Цена, Сумма, Вопрос как правильно организовывать остатки в БД Пока крутятся несколько способов 1. считать на ходу подбивать приходы – расходы есть текущий остаток. Способ хороший но если база хорошо вырастит то это будет не быстро. 2. Способ создать таблиц которая в конце каждого дня будет иметь остаток Имеем + по скорости но если документ поменяют задним числом то нужно от этого числа пересчитывать эту таблицу 3. Способ иметь простую таблицу без даты в которую при приходе просто будет Плюсоваться или отнимется количество + не нужно пересчитывать таблицу - Имеем только последние остатки а не на определенную дату. Как правильно организовать остатки какие есть еще решения. я бы выбрал второй способ. плюс не только по скорости но и по функциональности - имеем возможность быстро получать отчет на любую дату. таблицу действительно нужно пересчитывать. причем, наверное, будут менять не слишком "задним" числом. т.е. в рамках месяца-двух. так что пересчитать реально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 06:10 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
ZenForever, Имхо, третий способ. Потому как обычно нужны текущие остатки. Если кому-то очень уж сильно понадобятся остатки на дату, то такая выборка делается несложно, если база спроектирована хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 06:25 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sundukZenForever, Имхо, третий способ. Потому как обычно нужны текущие остатки. Если кому-то очень уж сильно понадобятся остатки на дату, то такая выборка делается несложно, если база спроектирована хорошо. Хм... со вторым все понятно, а вот с 3-м не представляю как можно грамотно спроектировать что бы получать остаки на дату если можете покажите пример... пожалуйста ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 06:32 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
ZenForever, остатки в таблице хранить по партиям. остаток на дату - текущий остаток - движение за период "дата"-сегодня. сейчас у меня такой подход работает на базе, где ~250тыс. партий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 06:44 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
ZenForeverкакие есть еще решения. Еще один вариант решения - закрывать отчетный период. Имеем входящий остаток на начало периода и исходящий на конец периода. Движение считается от последнего закрытого периода = входящий остаток + текущее движение. Работал в немаленькой торговой организации, в которой был реализован данный подход... Проблем с подсчетом остатков не возникало никаких. Отчетным периодом был месяц, на закрытие отчетного периода (с распечаткой всей первички, сверками и т.п.) отводилось порядка 3 рабочих дней следующего месяца. Будет интересно - стучите в асю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 10:02 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
bootty, и как решался вопрос, когда "очень уж нужно поправить документ 2-х месячной давности"? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 11:12 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sundukи как решался вопрос, когда "очень уж нужно поправить документ 2-х месячной давности"? :) "В лес" :) Таких исправлений на моей памяти не было, максимум прошлый отчетный, и то нечасто, из порядка 40 точек на 1-2 в месяц, чаще и вовсе без правок. Т.к. инициатором и заинтересованным лицом в такой ситуации была бухгалтерия, а не сотрудники отдела ИТ, то по их просьбе (согласованной со всеми и на всех уровнях) движение и входящие-исходящие остатки менялись с перепечаткой измененной первички. Технически проблем не было, средств для проверки сделано было более, чем достаточно, само закрытие было неплохо автоматизировано. Предполагаю, что если "очень-очень-очень" понадобилось бы и не было бы возможности исправить косяк в текущем времени (а варианты есть: сторно, обратные операции), то последовательно откатили б назад в обратном порядке и перезакрыли в правильном. Ажопаделать, если бизнесу нужно :) ЗЫ. А я не понимаю, как Вы сможете с Вашим подходом выдать остатки на ЛЮБУЮ дату. Необходимость этого имеется. Партионный учет подразумевался априори. Поделитесь? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 12:24 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
bootty, Увы, такие исправления (задним числом) не такие частые, но случаются с завидным постоянством. :) Партионный учет - да, априори. А остаток на любую дату - элементарно: есть текущий остаток, от него отнимаем движение за период "нужная дата"-"сегодня". Все довольно быстро работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 13:44 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
boottyЕще один вариант решения - закрывать отчетный период. Имеем входящий остаток на начало периода и исходящий на конец периода. Движение считается от последнего закрытого периода = входящий остаток + текущее движение. Собственно это есть частный случай варианта №2. Только специально закрывать дату не нужно (хм... а не нужно ли??? пусть автоматически...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 14:31 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sundukУвы, такие исправления (задним числом) не такие частые, но случаются с завидным постоянством. :) Могу Вам только посочувствовать :) В торговой организации, чтобы избежать этого, достаточно ежедневно выверять товародвижение с кассой и отслеживать несоответствия движения товара между подразделениями. В нашей схеме проблемы возникают не с количеством, а с себестоимостью при перемещении товаров, и это проблема не системная, обычно решаемая в пределах незакрытого периода. Проблем с остатками товара НЕТ :) (несколько десятков тысяч активных номенклатур, сотни тысяч, а на складе более миллиона активных партионов) sundukА остаток на любую дату - элементарно: есть текущий остаток, от него отнимаем движение за период "нужная дата"-"сегодня". Все довольно быстро работает. Но для того, чтобы проверить текущие остатки, нужно пересчитать ВСЕ движение. "Всё правильно сделал!" Может это и есть причина постоянства исправлений? ;) KOT MATPOCKuHСобственно это есть частный случай варианта №2. Только специально закрывать дату не нужно (хм... а не нужно ли??? пусть автоматически...) Согласен, частный случай. Нам удобно закрывать отчетный период - месяц - для бухгалтерии и больше к нему не возвращаться. И бухгалтерии удобно. Следовательно, нам нужно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 00:56 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
bootty, постоянство исправлений пропорционально идиотизму бухгалтеров. а зачем "проверять текущие остатки"? они всегда есть в актуальном состоянии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2008, 09:45 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sundukbootty, постоянство исправлений пропорционально идиотизму бухгалтеров. а зачем "проверять текущие остатки"? они всегда есть в актуальном состоянии.Сразу видно, Вы не работали с быстрооборачиваемым товаром...... и вороватыми кладовщиками с провинции. А текучка ? А передача дел ? Даже пойманный вор это повод провести выборочную инвентаризацию (чтоб на него повесить). :) Проверять надо. И по возможности чаще. Иначе не найти концов. Существует сто причин нарушения равенства "кол-во в компьютере" = "полка на складе". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2008, 12:34 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
LSV, секунду, текущие остатки в базе и соответствие их тому, что лежит на полке - это несколько разные вещи. bootty имел в виду, как я понял, что текущие остатки в БД нужно постоянно пересчитывать. а инвентаризацию провести и документами движения на основании сличительной ведомости привести остатки в базе к реальному состоянию - да не вопрос. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2008, 12:50 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
LSV, секунду, текущие остатки в базе и соответствие их тому, что лежит на полке - это несколько разные вещи. bootty имел в виду, как я понял, что текущие остатки в БД нужно постоянно пересчитывать. а инвентаризацию провести и документами движения на основании сличительной ведомости привести остатки в базе к реальному состоянию - да не вопрос. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2008, 12:56 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
LSV, секунду, текущие остатки в базе и остатки на полках - это немного разные вещи. провести инвентаризацию и привести документами движения остатки в базе в соответствие с тем, что лежит на полке на основании сличительной ведомости - да не вопрос. booty, имхо, предлагал пересчитывать текущие остатки в базе постоянно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2008, 14:01 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sunduk bootty имел в виду, как я понял, что текущие остатки в БД нужно постоянно пересчитывать. bootty имел ввиду, что если есть отдельная таблица остатков, то её нужно регулярно сверять с движением; так же он считает, что нет смысла в отдельной таблице для текущих остатков, т.к. они - величина вычисляемая, и достаточно остатков на дату, но эти остатки должны быть верны на 200%. ЗЫ. Идиотизм бухгатерии обратно пропорционален размеру её материальной заинтересованности. У нас было так: не закрыли отчетный период в срок по регламенту => "мотивация" = 0 . Есть необходимость открыть закрытый период по прихоти бухгалтерии => "мотивация" < 0 . Странно, но работало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 15:46 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
bootty bootty ... считает, что нет смысла в отдельной таблице для текущих остатков, т.к. они - величина вычисляемая, и достаточно остатков на дату... Собственно, в теме обсуждались в основном два альтернативных варианта (№2 и №3): - Считать только текущие остатки, остальные потребности пересчитывать от текущих; - Считать остатки на некоторый момент времени, а текущие и прочие потребности пересчитывать от них. Смешивать технологии не имеет смысла :) bootty +1 bootty ... но эти остатки должны быть верны на 200%. Любые остатки должны быть верны... Желаемое - не всегда действительное. sunduk bootty имел в виду, как я понял, что текущие остатки в БД нужно постоянно пересчитывать Под "постоянно" имеется ввиду и то, например, что пользователю для создания какого-либо документа нужно видеть текущие остатки. Варианты с "не текущими остатками" требуют расчета этих текущих остатков. А если пользователей 10, 100, 1000? Сервер только и будет снова и снова пересчитывать одни и те же значения. Чаще клиентская реализация показывает пользователю для выбора весь список номенклатуры с текущими остатками, а пользователь из них выбирает только 1..10 строк. А остальное сервер исправно все-равно должен посчитать. sunduk booty, имхо, предлагал пересчитывать текущие остатки в базе постоянно. Ага. Вопрос только в объеме пересчета: или "от царя гороха" (вариант №1) или от начала суток (вариант №2) или вообще не считать - взять уже посчитанные в момент внесения изменений(вариант №3) Вроде бы вариант №3 более производительный (для сервера/программиста), но не очень удобный пользователям. Пользователям проще работать с периодами: приходит человек на работу (продавец, кладовщик, ....), получает остатки на начало периода (дня, недели, месяца). А в конце работы "крыжит" все движение, сделанное за этот период. Любые ошибки (человеческий фактор ни кто не отменял) проще найти частями, например, периодами. Все это особенно становится важным при одновременной работе нескольких человек. Да и проверенный период можно "закрыть" от изменений - чтобы не портить отчетность за прошлый период, чтобы отсечь "много лет работы" от неконтролируемых изменений, внесенных "сегодня". И все же еще одно замечание: Остатки - в основном это денормализация, направленная на увеличение производительности системы по определению остатков (любых). В принципе, ни кто не запрещает иметь и остатки на начало/конец периода, и текущие остатки. Целесообразность - решайте сами, зависит от проблем с производительностью системы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 11:07 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
KOT MATPOCKuH, авторПод "постоянно" имеется ввиду и то, например, что пользователю для создания какого-либо документа нужно видеть текущие остатки. Варианты с "не текущими остатками" требуют расчета этих текущих остатков. А если пользователей 10, 100, 1000? Сервер только и будет снова и снова пересчитывать одни и те же значения. Чаще клиентская реализация показывает пользователю для выбора весь список номенклатуры с текущими остатками, а пользователь из них выбирает только 1..10 строк. А остальное сервер исправно все-равно должен посчитать. Текущие остатки нужны постоянно и для продажников и для склада. Для чего и делается таблица в которой при каждом движении пересчитывается остаток для соответствующей партии. В итоге мы всегда имеем под рукой готовые текущие остатки. Вот только объясните, пожалуйста, зачем часто и разным людям могут быть нужны остатки прошлых периодов? авторприходит человек на работу (продавец, кладовщик, ....), получает остатки на начало периода (дня, недели, месяца). А в конце работы "крыжит" все движение, сделанное за этот период. Вообще-то, приход материально-ответственного человека на работу сопровождается инвентаризацией. В итоге человеку передаются материальные ценности по результатам инвентаризации. Вопрос - зачем ему остатки на начало какого-либо периода? авторЛюбые ошибки (человеческий фактор ни кто не отменял) проще найти частями, например, периодами. Все это особенно становится важным при одновременной работе нескольких человек. Вот это вообще непонятно. Какие ошибки можно найти посмотрев движение чего-либо за какой-то определенный период времени? Ошибка чаще всего возникает по какой-либо партии или номенклатурному наименованию, и эту ошибку не проанализировав все движение по партии не найдешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 12:03 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sunduk ... В итоге мы всегда имеем под рукой готовые текущие остатки. Именно это я и имел ввиду (вроде даже написал) sunduk Вот только объясните, пожалуйста, зачем часто и разным людям могут быть нужны остатки прошлых периодов? Не часто. В зависимости от периода. Если период месяц, то - совсем не часто. Если сутки или смена, то чаще. В основном нужно для корректировок, проведения операций "задним числом", устранения пересортицы, исправление "кривых рук" и т.д. и т.п. В кривых системах - для уменьшения отгрузки при возврате товара (видел такое) sundukавторприходит человек на работу (продавец, кладовщик, ....), получает остатки на начало периода (дня, недели, месяца). А в конце работы "крыжит" все движение, сделанное за этот период. Вообще-то, приход материально-ответственного человека на работу сопровождается инвентаризацией. В итоге человеку передаются материальные ценности по результатам инвентаризации. Вопрос - зачем ему остатки на начало какого-либо периода? Ага! И этот человек там днюет и ночует, никому по смене не передает... Или по Вашему нужно в начале каждой смены делать полную инвентаризацию? Видимо Вы сталкивались с маленькими складами. Лично недавно участвовал в одной инвентаризации: проводилась круглосуточно (в три смены по 8 часов) в течении 26 суток, без остановки производственного процесса. Объем можете себе представить! :( И кладовщики там тоже работают по-сменно, передают по смене "электронные" остатки. Каждый отвечает за движение в своей смене - это он и проверяет и подписывает. sundukавторЛюбые ошибки (человеческий фактор ни кто не отменял) проще найти частями, например, периодами. Все это особенно становится важным при одновременной работе нескольких человек. Вот это вообще непонятно. Какие ошибки можно найти посмотрев движение чего-либо за какой-то определенный период времени? Ошибка чаще всего возникает по какой-либо партии или номенклатурному наименованию, и эту ошибку не проанализировав все движение по партии не найдешь. Конечно я имел ввиду не движение чего-либо вообще, а именно по "...какой-либо партии или номенклатурному наименованию...". Речь в данном контексте шла о временном факторе. Кроме этих есть (может быть) ряд других факторов, о которых в данной теме мы речь не ведем. Для чего предлагается период пояснить нужно? (мне кажется это тривиальным, но это с моего опыта, может кому не понятно?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 12:40 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
KOT MATPOCKuH, А смысл передачи электронных остатков? Выяснить какая фактура потерялась/забыли увезти и т.д.? Для этого есть другие, более гибкие способы. При факте кражи/недостачи это также не поможет выяснить виновника. При больших объемах реальные остатки передать по смене практически невозможно. Как делалось у нас - большой склад делится на несколько участков, за которыми закрепляется несколько ответственных лиц и подписывается договор о коллективной мат. ответственности. На складе естественно ведется адресная система. В результате недостач стало на порядок меньше. При этом инвентаризацию можно провести на отдельно взятом участке. авторКонечно я имел ввиду не движение чего-либо вообще, а именно по "...какой-либо партии или номенклатурному наименованию...". Речь в данном контексте шла о временном факторе. Кроме этих есть (может быть) ряд других факторов, о которых в данной теме мы речь не ведем. Для чего предлагается период пояснить нужно? (мне кажется это тривиальным, но это с моего опыта, может кому не понятно?) Я думаю, что пояснить нужно, потому как мысль не уловил.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 15:00 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sundukВот только объясните, пожалуйста, зачем часто и разным людям могут быть нужны остатки прошлых периодов?Для планирования. sundukОшибка чаще всего возникает по какой-либо партии или номенклатурному наименованию, и эту ошибку не проанализировав все движение по партии не найдешь.В варианте с закрытием периодов поиск сводится к поиску за небольшой срок, а не к поиску по всему движению по партии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 15:18 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
bootty, автор Для планирования. согласен, но необходимость в этих данных возникает нечасто. автор В варианте с закрытием периодов поиск сводится к поиску за небольшой срок, а не к поиску по всему движению по партии главное - этот срок правильно определить. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 15:23 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sundukbootty, автор В варианте с закрытием периодов поиск сводится к поиску за небольшой срок, а не к поиску по всему движению по партии главное - этот срок правильно определить. :) Так оно. Еще бывают вложенные периоды. Отдельно, например, смена, отдельно сутки, месяц, квартал, год - для разных нужд, разных подразделений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2008, 09:10 |
|
||
|
Остатки в торговой БД
|
|||
|---|---|---|---|
|
#18+
sundukавторДля планирования. согласен, но необходимость в этих данных возникает нечасто.Она не возникает, а имеется постоянно в разных разрезах и за разные периоды. И в остатках, и в движении номенклатур. ЗЫ. Время, когда покупали все подряд и за любые деньги, уже давно закончилось, уважаемый. Поэтому требуется постоянный мониторинг и внесение корректировок в существующие планы. sundukавторВ варианте с закрытием периодов поиск сводится к поиску за небольшой срок, а не к поиску по всему движению по партии главное - этот срок правильно определить. :)Он уже определен - это конец последнего закрытого периода/начало текущего. Один из результатов выверок и закрытия периодов - отсутствие необходимости возвращаться назад. В вашей организации свои процессы и свои потребности в данных, в нашей - другие. Каждый строит работу так, как удобнее в конкретной организации. Предлагаю на этом и закончить прения :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2008, 09:44 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35639727&tid=1543573]: |
0ms |
get settings: |
10ms |
get forum list: |
22ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
229ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
| others: | 246ms |
| total: | 602ms |

| 0 / 0 |
