У меня вопрос по проектированию модели данных для складов. Общие требования к разрабатываемой системе такие:
1. Есть несколько складов. На складе располагаются товары.
2. Есть операции приемки товара на склад, перемещения на другой склад и списания со склада.
3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год)
4. Необходимо хранить данные по прошедшим операциям.
5. Необходима возможность отмены и изменения прошедшей операции приемки/перемещения/списания.
6. Прошедшие операции следует хранить не более 1 года.
Какой подход избрать для проектирования модели данных?
У меня в голове сейчас 3 варианта.
1 вариант. Не хранить, сколько товара было на складе в каждый конкретный момент. Хранить только операции, например:
Товар Склад Кол-во Дата Тип операции
----------------------------------------------------
Телевизор С1 +8 март Приход
Телевизор С1 -1 апрель Расход
Телевизор С2 +1 апрель Приход
Тогда мы можем агрегировать эти операции по складу и товару и получить количество товара на заданную дату. Легко отменить операцию — просто не учитывать ее при агрегировании. Однако старые операции должны храниться только 1 год, а затем удаляться, значит мы потеряем данные. Кроме того, чтобы получить состояние складов на сегодня, придется выгружать всю таблицу операций в память, чтобы провести агрегирование — теряем в производительности.
2 вариант. Хранить и операции, и состояние товара на складе. Причем состояние товара — это версионные данные. Например:
Товар Склад Кол-во Дата
-----------------------------------
Телевизор С1 8 март
Телевизор С1 7 апрель
Телевизор С2 1 апрель
Теперь мы можем удалять старые операции и даже старые записи из таблицы состояние складов. Однако размер БД увеличивается и появляются сложности с отменой прошлых операции. Чтобы отменить операцию, нужно провести цепочку изменений в таблице состояния склада — ведь изменятся все последующие записи, связанные с данным товаром.
Вероятно, имеет право на жизнь 3 вариант, который является комбинацией 1 и 2 вариантов. В нем мы заводим табличку "базового" состояния складов, которое было до совершения первой неудаленной операции. Тогда, при удалении устаревших операций, мы применяем их к "базовому" состоянию складов. А состояние складов за определенную дату получается путем объединения "базового" состояния и операций до этой даты.
А какое Ваше мнение, господа?
Заранее всем спасибо.
Re: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>6. Прошедшие операции следует хранить не более 1 года.
Странное требование на самом деле. Может стоит не показывать операции более одного года?
R>1 вариант. Не хранить, сколько товара было на складе в каждый конкретный момент. Хранить только операции
Это называется двойной бухгалтерской записью, должно применяться для любого учета движения денег или товаров.
R>...Кроме того, чтобы получить состояние складов на сегодня, придется выгружать всю таблицу операций в память, чтобы провести агрегирование — теряем в производительности.
materialized\indexed views
R>А какое Ваше мнение, господа?
В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
Алгоритм получения остатков на любую дату будет одинаковым.
Есть еще один неприятный момент отказа от хранения всей истории — невозможность получить бухгалтерскую отчетность и проводить анализ, например выявлять сезонность товаров.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, ronaldo9, Вы писали:
R>>6. Прошедшие операции следует хранить не более 1 года. G>Странное требование на самом деле. Может стоит не показывать операции более одного года?
В данном случае число лет может быть 3, и 5, и 10. Суть в том, что размер БД должен быть как-то ограничен.
Спасибо за ответ. Можно ли где-нибудь еще почитать по данной теме?
Re[3]: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, ronaldo9, Вы писали:
R>>>6. Прошедшие операции следует хранить не более 1 года. G>>Странное требование на самом деле. Может стоит не показывать операции более одного года?
R>В данном случае число лет может быть 3, и 5, и 10. Суть в том, что размер БД должен быть как-то ограничен.
Зачем?
Здравствуйте, ronaldo9, Вы писали:
R>Здравствуйте.
R>У меня вопрос по проектированию модели данных для складов. Общие требования к разрабатываемой системе такие: R>1. Есть несколько складов. На складе располагаются товары. R>2. Есть операции приемки товара на склад, перемещения на другой склад и списания со склада. R>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год) R>4. Необходимо хранить данные по прошедшим операциям. R>5. Необходима возможность отмены и изменения прошедшей операции приемки/перемещения/списания.
...
1. В любой автоматизированной учетной системе Вы встретите:
— Операции прихода (Дата, Склад, Товар, Кол-во, Некая аналитика — откуда поступило)
— Операции перемещения (Дата, Склад получатель, Склад отправитель, Товар, Кол-во)
— Операции расхода (Дата, Некая аналитика — куда ушло, Склад, Товар, Кол-во)
2. Первоначальные остатки на складе формируются через Операции поступления предыдущим периодом
3. Состояние склада рассчитывается на любую дату
4. В случае большого объема данных, когда сервер СУБД действительно НЕ СПРАВЛЯЕТСЯ, вводится понятие Срез.
В отдельном срезе формируются остатки по складу на определенную дату (Дата, Склад, Товар, Остаток).
Состояние склада рассчитывается на порядок быстрее с учетом среза и операций прошедших только после него.
Однако, механизм Срезов на порядок усложняет систему:
— Необходимо на уровне СУБД запретить исправление операций, проводимых датой раньше любого существующего среза.
— Или пересчитывать все срезы идущие датой после операции
— Функция расчета состояния склада с учетом срезов в реальных задачах имеет массу подводных камней
R>6. Прошедшие операции следует хранить не более 1 года.
Странное условие, если оно не обоснованно техническими ограничениями
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, sereginseregin, Вы писали:
S>Здравствуйте, ronaldo9, Вы писали:
R>>Здравствуйте.
R>>У меня вопрос по проектированию модели данных для складов. Общие требования к разрабатываемой системе такие: R>>1. Есть несколько складов. На складе располагаются товары. R>>2. Есть операции приемки товара на склад, перемещения на другой склад и списания со склада. R>>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год) R>>4. Необходимо хранить данные по прошедшим операциям. R>>5. Необходима возможность отмены и изменения прошедшей операции приемки/перемещения/списания.
S>...
S>1. В любой автоматизированной учетной системе Вы встретите: S>- Операции прихода (Дата, Склад, Товар, Кол-во, Некая аналитика — откуда поступило) S>- Операции перемещения (Дата, Склад получатель, Склад отправитель, Товар, Кол-во) S>- Операции расхода (Дата, Некая аналитика — куда ушло, Склад, Товар, Кол-во)
Поправка: в хреновой системе встретите, в нормальной системе будет двойная бухгалтерская запись, которая одинаково выражает все операции выше.
S>4. В случае большого объема данных, когда сервер СУБД действительно НЕ СПРАВЛЯЕТСЯ, вводится понятие Срез.
Никаких понятий не надо, сами проводки довольно редко надо получать, надо иметь остаток на дату и обороты за период.
Создается материализованная вьюха в базе, которая суммирует все проводки группируя по датам и аналитикам. Это получатся обороты за день.
Движок материализации в современных субд довольно умен чтобы при измененнии не пересчитывать все.
Остатки — сумма оборотов с начала. Оборот за период — сумма в периоде.
Для большей оптимизации можно ввести дополнительные группировки, например по месяцам, кварталам и годам. Тогда для расчета оборотов в большом периоде и остатков не нужно бегать по всей вьюхе по дням. Это реализуется inline функциями в субд.
И не нужно хранить "срезы" отдельной сущностью.
Причем всю аналитику можно возложить на умный OLAP, который сам все посчитает, только возможность увидеть остатки сразу после операции оприходования пропадет.
Re: Задачка: модель данных для склада с версионностью
> Какой подход избрать для проектирования модели данных?
Проведи анализ. Нужно взять Бухгалтера по товарным запасам (или как они
там классифицируются) и пусть он Вас научит складскому учету. Как только
научитесь, сможете спроектировать систему.
Там будет много чего...
Остатки, накладные, акты. Какие-нибудь инвентаризации, списания в
результате порчи, пересортица, недостачи и возмещения.
Вообще там будет несколько срезов. Один по деньгам (он же используется в
баллансовых отчетах). Другой срез по кол-ву товаров. Там еще выплывут
всякие партии поставок, сроки годности...
В общем — нужно чтобы во время проектирования системы рядом сидел бухгалтер.
И еще стоит рассмотреть вопрос лицензирования какого-нибудь решения.
Думаю найдется такое, которое Вам подойдет.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, ronaldo9, Вы писали:
R>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, ronaldo9, Вы писали:
R>>>>6. Прошедшие операции следует хранить не более 1 года. G>>>Странное требование на самом деле. Может стоит не показывать операции более одного года?
R>>В данном случае число лет может быть 3, и 5, и 10. Суть в том, что размер БД должен быть как-то ограничен. G>Зачем?
Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, Other Sam, Вы писали:
>> Какой подход избрать для проектирования модели данных?
OS>Проведи анализ. Нужно взять Бухгалтера по товарным запасам (или как они OS>там классифицируются) и пусть он Вас научит складскому учету. Как только OS>научитесь, сможете спроектировать систему.
Далеко не все бухгалтеры так сильны в математической модели учета, как хотелось бы.
OS>Там будет много чего... OS>Остатки, накладные, акты. Какие-нибудь инвентаризации, списания в OS>результате порчи, пересортица, недостачи и возмещения. OS>Вообще там будет несколько срезов. Один по деньгам (он же используется в OS>баллансовых отчетах). Другой срез по кол-ву товаров. Там еще выплывут OS>всякие партии поставок, сроки годности...
Смешались в кучу кони, люди...
OS>В общем — нужно чтобы во время проектирования системы рядом сидел бухгалтер.
См выше.
OS>И еще стоит рассмотреть вопрос лицензирования какого-нибудь решения. OS>Думаю найдется такое, которое Вам подойдет.
1С торговля и склад.
Re[5]: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, ronaldo9, Вы писали:
R>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, ronaldo9, Вы писали:
R>>>>>6. Прошедшие операции следует хранить не более 1 года. G>>>>Странное требование на самом деле. Может стоит не показывать операции более одного года?
R>>>В данном случае число лет может быть 3, и 5, и 10. Суть в том, что размер БД должен быть как-то ограничен. G>>Зачем? R>Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.
Используйте SQL Server 2008 R2, там 10 ГБ.
А вообще задумайтесь о покупке Standart версии, там Olap есть.
Re[6]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
R>>>>В данном случае число лет может быть 3, и 5, и 10. Суть в том, что размер БД должен быть как-то ограничен. G>>>Зачем? R>>Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.
G>Используйте SQL Server 2008 R2, там 10 ГБ.
Гигибайты баз — не самое большое ограничение, гораздо хреновее ограничение в используемой памяти в 1 гб, на больших объемах сильно бъет по производительности.
Re[3]: Задачка: модель данных для склада с версионностью
S>>1. В любой автоматизированной учетной системе Вы встретите... G>Поправка: в хреновой системе встретите, в нормальной системе будет двойная бухгалтерская запись, которая одинаково выражает все операции выше.
Не знаю пока такой охренненой учетной системы, в которой только одна таблица проводок. Необходимы еще отдельные таблицы для всяких документов (приход, перемещение, расход, ...). Невозможно всю аналитику, необходимую для управленческих нужд, засунуть в проводку. Слишком большое разнообразие данных и логики. XML поля тоже не помогут.
Но, возможно, к данной задаче это не относится...
G>Создается материализованная вьюха в базе, которая суммирует все проводки группируя по датам и аналитикам. Это получатся обороты за день. G> ... G>Для большей оптимизации можно ввести дополнительные группировки, например по месяцам, кварталам и годам. Тогда для расчета оборотов в большом периоде и остатков не нужно бегать по всей вьюхе по дням. Это реализуется inline функциями в субд. G>И не нужно хранить "срезы" отдельной сущностью. G>Причем всю аналитику можно возложить на умный OLAP, который сам все посчитает, только возможность увидеть остатки сразу после операции оприходования пропадет.
Я предпочитаю запускать расчет среза отдельной сущностью (а не "материализованная вьюха") в базе в конце рабочего дня, когда в системе минимальная нагрузка и мой расчет не тормозит систему у пользователей. А функция расчета остатков сама определяет, какой срез ближайший, оставшиеся обороты собирает из проводок. Собирать обороты по дням, месяцам, годам не было необходимости.
Re[6]: Задачка: модель данных для склада с версионностью
Здравствуйте, sereginseregin, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>1. В любой автоматизированной учетной системе Вы встретите... G>>Поправка: в хреновой системе встретите, в нормальной системе будет двойная бухгалтерская запись, которая одинаково выражает все операции выше. S>Не знаю пока такой охренненой учетной системы, в которой только одна таблица проводок. Необходимы еще отдельные таблицы для всяких документов (приход, перемещение, расход, ...). Невозможно всю аналитику, необходимую для управленческих нужд, засунуть в проводку. Слишком большое разнообразие данных и логики. XML поля тоже не помогут.
Надо было весь кусок цитировать. Были указаны три, вроде как различные, операции, хотя с головой хватает двойной бухгалтерской записи. Я не говорил о документах, таблицах и тому подобном.
G>>Создается материализованная вьюха в базе, которая суммирует все проводки группируя по датам и аналитикам. Это получатся обороты за день. G>> ... G>>Для большей оптимизации можно ввести дополнительные группировки, например по месяцам, кварталам и годам. Тогда для расчета оборотов в большом периоде и остатков не нужно бегать по всей вьюхе по дням. Это реализуется inline функциями в субд. G>>И не нужно хранить "срезы" отдельной сущностью. G>>Причем всю аналитику можно возложить на умный OLAP, который сам все посчитает, только возможность увидеть остатки сразу после операции оприходования пропадет.
S>Я предпочитаю запускать расчет среза отдельной сущностью (а не "материализованная вьюха") в базе в конце рабочего дня, когда в системе минимальная нагрузка и мой расчет не тормозит систему у пользователей.
А думаешь материализованные вьюхи будут что-то тормозить? Не так часто добавляются проводки чтобы пересчет серьезно влиял на скорость работы.
S>А функция расчета остатков сама определяет, какой срез ближайший, оставшиеся обороты собирает из проводок. Собирать обороты по дням, месяцам, годам не было необходимости.
Ты сам себе противоречишь. Обороты по дням, месяцам, годам — это выполняют ту же функцию что твои "срезы", только считаются они автоматически в момент запроса и при этом имеют ту же самую структуру что и все остальные проводки, поэтому банально union писать легче в функции расчета остатков.
Re[5]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Были указаны три, вроде как различные, операции, хотя с головой хватает двойной бухгалтерской записи. Я не говорил о документах, таблицах и тому подобном.
Для бухгалтерии хватает, для управленческого учета не всегда. Часто приходится собирать в реальном времени остатки и обороты по документам.
G>А думаешь материализованные вьюхи будут что-то тормозить? Не так часто добавляются проводки чтобы пересчет серьезно влиял на скорость работы.
У нас в год 3000000 проводок (8500 в день). Расшифровки остатков и оборотов бухгалтера собирают вдоль и поперек тоже ежесекундно, их не остановтЬ
G>Ты сам себе противоречишь. Обороты по дням, месяцам, годам — это выполняют ту же функцию что твои "срезы", только считаются они автоматически в момент запроса и при этом имеют ту же самую структуру что и все остальные проводки, поэтому банально union писать легче в функции расчета остатков.
Может не так выразился, собирать СРЕЗЫ оборотов не было необходимости, postgres пока справляется.
Re[6]: Задачка: модель данных для склада с версионностью
Здравствуйте, sereginseregin, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Были указаны три, вроде как различные, операции, хотя с головой хватает двойной бухгалтерской записи. Я не говорил о документах, таблицах и тому подобном. S>Для бухгалтерии хватает, для управленческого учета не всегда. Часто приходится собирать в реальном времени остатки и обороты по документам.
Двойная бухгалтерская запись этому никак не мешает, а только помогает. Из-за того что все операции хранятся едино кода расчетов получается проще.
G>>А думаешь материализованные вьюхи будут что-то тормозить? Не так часто добавляются проводки чтобы пересчет серьезно влиял на скорость работы. S>У нас в год 3000000 проводок (8500 в день).
В среднем одна проводка в 2 сек. Не страшно для пересчета.
Re[3]: Задачка: модель данных для склада с версионностью
>> > Какой подход избрать для проектирования модели данных? > > OS>Проведи анализ. Нужно взять Бухгалтера по товарным запасам (или как они > OS>там классифицируются) и пусть он Вас научит складскому учету. Как только > OS>научитесь, сможете спроектировать систему. > Далеко не все бухгалтеры так сильны в математической модели учета, как > хотелось бы.
Не верно. У квалифицированного бухгалтера должно хватать на это знаний.
Иначе он не бухгалтер.
> > OS>Там будет много чего... > OS>Остатки, накладные, акты. Какие-нибудь инвентаризации, списания в > OS>результате порчи, пересортица, недостачи и возмещения. > OS>Вообще там будет несколько срезов. Один по деньгам (он же используется в > OS>баллансовых отчетах). Другой срез по кол-ву товаров. Там еще выплывут > OS>всякие партии поставок, сроки годности... > Смешались в кучу кони, люди...
О чем это вы?
> OS>В общем — нужно чтобы во время проектирования системы рядом сидел > бухгалтер. > См выше. > > OS>И еще стоит рассмотреть вопрос лицензирования какого-нибудь решения. > OS>Думаю найдется такое, которое Вам подойдет. > 1С торговля и склад.
Возможно.
---
gangjustas, зачем был ваш пост?
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Задачка: модель данных для склада с версионностью
Здравствуйте, Other Sam, Вы писали:
>>> > Какой подход избрать для проектирования модели данных? >> >> OS>Проведи анализ. Нужно взять Бухгалтера по товарным запасам (или как они >> OS>там классифицируются) и пусть он Вас научит складскому учету. Как только >> OS>научитесь, сможете спроектировать систему. >> Далеко не все бухгалтеры так сильны в математической модели учета, как >> хотелось бы.
OS>Не верно. У квалифицированного бухгалтера должно хватать на это знаний. OS>Иначе он не бухгалтер.
Сама предметная область и её мат. модель — сильно разные вещи бывают.
При развитии компьютерных систем все чаще бухгалтеры оперируют не проводками, остатками и оборотами, а "документами", "товаром на складе", "доходами", "налогами" и другими объектами, специфичными для бизнеса.
>> >> OS>Там будет много чего... >> OS>Остатки, накладные, акты. Какие-нибудь инвентаризации, списания в >> OS>результате порчи, пересортица, недостачи и возмещения. >> OS>Вообще там будет несколько срезов. Один по деньгам (он же используется в >> OS>баллансовых отчетах). Другой срез по кол-ву товаров. Там еще выплывут >> OS>всякие партии поставок, сроки годности... >> Смешались в кучу кони, люди...
OS>О чем это вы?
О том что не надо все мешать в одну кучу.
OS>gangjustas, зачем был ваш пост?
Примерно о том же что и ваш: о том как писать учет и как его не писать.
Re: Задачка: модель данных для склада с версионностью
> Сама предметная область и её мат. модель — сильно разные вещи бывают. > При развитии компьютерных систем все чаще бухгалтеры оперируют не > проводками, остатками и оборотами, а "документами", "товаром на складе", > "доходами", "налогами" и другими объектами, специфичными для бизнеса. >
И правильно делают! Система должна подстраиваться под людей, а не люди
под систему! Пофиг какая там мат модель, бухгалтер должен там увидеть
то, что он ожидает. Ожидает "документ" — значит должен быть документ.
Как это будет устроенно внутри — это для бухгалтера не имеет никакого
значения.
Что хочу сказать? Пользователь прав! В данном случае — бухгалтер прав!
Читайте "Психбольница в руках пациентов" Алана... забыл фамилию.
>> > >> > OS>Там будет много чего... >> > OS>Остатки, накладные, акты. Какие-нибудь инвентаризации, списания в >> > OS>результате порчи, пересортица, недостачи и возмещения. >> > OS>Вообще там будет несколько срезов. Один по деньгам (он же > используется в >> > OS>баллансовых отчетах). Другой срез по кол-ву товаров. Там еще выплывут >> > OS>всякие партии поставок, сроки годности... >> > Смешались в кучу кони, люди... > > OS>О чем это вы? > О том что не надо все мешать в одну кучу.
Прелагайте как разделить эти вещи по разным кучам. Я выслушаю.
Posted via RSDN NNTP Server 2.1 beta
Re[6]: Задачка: модель данных для склада с версионностью
Здравствуйте, Other Sam, Вы писали:
>> Сама предметная область и её мат. модель — сильно разные вещи бывают. >> При развитии компьютерных систем все чаще бухгалтеры оперируют не >> проводками, остатками и оборотами, а "документами", "товаром на складе", >> "доходами", "налогами" и другими объектами, специфичными для бизнеса. >>
OS>И правильно делают! Система должна подстраиваться под людей, а не люди OS>под систему! Пофиг какая там мат модель, бухгалтер должен там увидеть OS>то, что он ожидает. Ожидает "документ" — значит должен быть документ.
Именно.
OS>Как это будет устроенно внутри — это для бухгалтера не имеет никакого OS>значения.
Зато для программиста имеет большое значения. Вот об этом я и говорю.
OS>Что хочу сказать? Пользователь прав! В данном случае — бухгалтер прав!
Пользователь всегда прав.
OS>Читайте "Психбольница в руках пациентов" Алана... забыл фамилию.
Купер.
>>> > >>> > OS>Там будет много чего... >>> > OS>Остатки, накладные, акты. Какие-нибудь инвентаризации, списания в >>> > OS>результате порчи, пересортица, недостачи и возмещения. >>> > OS>Вообще там будет несколько срезов. Один по деньгам (он же >> используется в >>> > OS>баллансовых отчетах). Другой срез по кол-ву товаров. Там еще выплывут >>> > OS>всякие партии поставок, сроки годности... >>> > Смешались в кучу кони, люди... >> >> OS>О чем это вы? >> О том что не надо все мешать в одну кучу.
OS>Прелагайте как разделить эти вещи по разным кучам. Я выслушаю.
Вкратце суть: нижний уровень — двойная бухгалтерская запись, выше — документооборот, между ними множество отображения документов в проводки,
сбоку — система справочников, которая хранит контрагентов, товары, номера счетов.
Отображения документов лучше делать каким-нить скриптовым языком, а в идеале текстовым DSL, чтобы менять можно было.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, ronaldo9, Вы писали:
R>>Здравствуйте.
R>>У меня вопрос по проектированию модели данных для складов.
R>>А какое Ваше мнение, господа?
G>А почему не 1С?
Не могу ответить на этот вопрос — не моя зона ответственности. Нужно написать заказное ПО.
Re[5]: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>>>В данном случае число лет может быть 3, и 5, и 10. Суть в том, что размер БД должен быть как-то ограничен. G>>Зачем? R>Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.
Забить проводками 4ГБ надо сильно постараться.
Re[3]: Задачка: модель данных для склада с версионностью
Лог всех операций (возможная отмена, перенакатывание и потенциально более высокие кол-во TX) + всевозможные виды, включая, аггрегирование, т.е. сколько ИТОГО на текущий момент времени запроса. (см. CQRS) Еще (лично) я бы подумал об уникальном идентификаторе для каждой операции.
Re: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>Вероятно, имеет право на жизнь 3 вариант, который является комбинацией 1 и 2 вариантов. В нем мы заводим табличку "базового" состояния складов, которое было до совершения первой неудаленной операции. Тогда, при удалении устаревших операций, мы применяем их к "базовому" состоянию складов. А состояние складов за определенную дату получается путем объединения "базового" состояния и операций до этой даты.
Думаю именно третий вариант. Вам тут насоветовали уже немало, хотя и без особой конкретики. Я думаю вам стоило бы начать с модели домена (предметной области). Например: Есть объект класса "Склад" который ссылается на множество объектов класса "Товар". Каждый объект "Товар" ссылается на цепочку "проводок". В "Проводке" есть дата, источник товара, сколько отгружено, остаток и ссылка на предыдущую "Проводку". Таким образом вы получаете остатки на текущий момент и историю произвольной глубины с возможностью откатиться по любому товару или по всем сразу. Историю можно обрезать и сохранить в архив когда потребуется. В реляционном рпедставлении думаю будут три таблицы: "Склады", "Товары", "Проводки". Ну а всякая статистика уже поверх этого ядра.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, ronaldo9, Вы писали:
R>>Вероятно, имеет право на жизнь 3 вариант, который является комбинацией 1 и 2 вариантов. В нем мы заводим табличку "базового" состояния складов, которое было до совершения первой неудаленной операции. Тогда, при удалении устаревших операций, мы применяем их к "базовому" состоянию складов. А состояние складов за определенную дату получается путем объединения "базового" состояния и операций до этой даты.
А.М>Думаю именно третий вариант.
Если ты так думаешь, то почему в своей модели домена не указал "базовое состояние" ?
А.М>Вам тут насоветовали уже немало, хотя и без особой конкретики.
Ты прямо конкретики рассказал...
А.М>Я думаю вам стоило бы начать с модели домена (предметной области). Например: Есть объект класса "Склад" который ссылается на множество объектов класса "Товар". Каждый объект "Товар" ссылается на цепочку "проводок". В "Проводке" есть дата, источник товара, сколько отгружено, остаток и ссылка на предыдущую "Проводку".Таким образом вы получаете остатки на текущий момент и историю произвольной глубины с возможностью откатиться по любому товару или по всем сразу. Историю можно обрезать и сохранить в архив когда потребуется. В реляционном рпедставлении думаю будут три таблицы: "Склады", "Товары", "Проводки". Ну а всякая статистика уже поверх этого ядра.
Ну и бредятина.
1) у проводки нету ссылки на склад, только на товар, значит чтобы отличать на какой склад пришел товар записи о товарах должны быть разными.
То есть кроссовки на складе 1 это не кроссовки на складе 2. И как тут обороты по всем кроссовкам получить?
2)Остаток хранится прямо в проводке, это значит при изменении проводки, которая была раньше надо пересчитывать все идущие после нее
3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной.
4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть.
Выкини свои книжки по DDD\ООП, изучай ER, РСУБД, olap и ботай бухучет.
Re[3]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>1) у проводки нету ссылки на склад, только на товар, значит чтобы отличать на какой склад пришел товар записи о товарах должны быть разными. G>То есть кроссовки на складе 1 это не кроссовки на складе 2. И как тут обороты по всем кроссовкам получить?
Тут ты прав, надо добавить "метатовар" кроссовки, который будет ссылаться на кроссовки на разных складах.
G>2)Остаток хранится прямо в проводке, это значит при изменении проводки, которая была раньше надо пересчитывать все идущие после нее
Остаток можно хранить в товаре, но его придется пересчитывать в любом случае, где бы он не хранился. Можно конечно и не хранить,
но тогда придется все время пересчитывать, чтобы узнать остатки.
G>3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной.
Добавляем класс/таблицу "Накладная" и ссылки на "проводки".
G>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть.
Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход.
Реляционные БД -- это только один из способов хранить данные. Есть и другие варианты.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, sereginseregin, Вы писали:
S>Однако, механизм Срезов на порядок усложняет систему: S>- Необходимо на уровне СУБД запретить исправление операций, проводимых датой раньше любого существующего среза. S>- Или пересчитывать все срезы идущие датой после операции
Проблема устраняется, если представить исправление/отмену операции в виде отдельной операции. Обычно в кассовых системах так и делается — выбивается отдельный чек на возврат денег, если отменяется продажа.
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, gandjustas, Вы писали:
G>>1) у проводки нету ссылки на склад, только на товар, значит чтобы отличать на какой склад пришел товар записи о товарах должны быть разными. G>>То есть кроссовки на складе 1 это не кроссовки на складе 2. И как тут обороты по всем кроссовкам получить? А.М>Тут ты прав, надо добавить "метатовар" кроссовки, который будет ссылаться на кроссовки на разных складах.
Нарисуйка er диаграмму, поймешь что все свойства товара должны быть в "метатоваре", а сам товар будет иметь ссылку на склад.
G>>2)Остаток хранится прямо в проводке, это значит при изменении проводки, которая была раньше надо пересчитывать все идущие после нее А.М>Остаток можно хранить в товаре
Нельзя. Нужно за периоды иметь остатки и обороты.
А.М>но его придется пересчитывать в любом случае, где бы он не хранился.
Да, только в твоем случае надо будет пересчитывать все остатки после даты изменения, а это мягко говоря дохорена окажется.
А.М>Можно конечно и не хранить,но тогда придется все время пересчитывать, чтобы узнать остатки.
Можно заставить БД пересчитывать, а самому не париться, но при этом не получится "доменная модель" как ты её описал.
G>>3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной. А.М>Добавляем класс/таблицу "Накладная" и ссылки на "проводки".
Именно так получаются самые ужасные бухгалтерские программы — добавлением таблиц на каждую необходимость.
G>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход.
И как эти псевдоотгрузки отличать от обычных отгрузок?
А.М>Реляционные БД -- это только один из способов хранить данные. Есть и другие варианты.
Сделай бухгалтерию на нереляционной БД, мы посмотрим.
Re[5]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, А.М, Вы писали:
А.М>>Здравствуйте, gandjustas, Вы писали:
А.М>>Тут ты прав, надо добавить "метатовар" кроссовки, который будет ссылаться на кроссовки на разных складах. G>Нарисуйка er диаграмму, поймешь что все свойства товара должны быть в "метатоваре", а сам товар будет иметь ссылку на склад.
Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим.
А.М>>но его придется пересчитывать в любом случае, где бы он не хранился. G>Да, только в твоем случае надо будет пересчитывать все остатки после даты изменения, а это мягко говоря дохорена окажется. А.М>>Можно конечно и не хранить,но тогда придется все время пересчитывать, чтобы узнать остатки. G>Можно заставить БД пересчитывать, а самому не париться, но при этом не получится "доменная модель" как ты её описал.
Но таки пересчитывать придется в любом случае, и мне кажется получение остатков более частая операция чем исправление проводки
сделанной в прошлом году.
G>>>3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной. А.М>>Добавляем класс/таблицу "Накладная" и ссылки на "проводки". G>Именно так получаются самые ужасные бухгалтерские программы — добавлением таблиц на каждую необходимость.
А вы что предлагаете? Если необходимость есть, надо добавлять, нет -- не добавлять. Или вы предпочитаете модель водопада?
G>>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>И как эти псевдоотгрузки отличать от обычных отгрузок?
По значению поля "Кому отгружаем".
А.М>>Реляционные БД -- это только один из способов хранить данные. Есть и другие варианты. G>Сделай бухгалтерию на нереляционной БД, мы посмотрим.
Почему нет? NoSQL пока может еще и сыроваты, но прогресс не стоит на месте.
Re[6]: Задачка: модель данных для склада с версионностью
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, А.М, Вы писали:
А.М>>>Здравствуйте, gandjustas, Вы писали:
А.М>>>Тут ты прав, надо добавить "метатовар" кроссовки, который будет ссылаться на кроссовки на разных складах. G>>Нарисуйка er диаграмму, поймешь что все свойства товара должны быть в "метатоваре", а сам товар будет иметь ссылку на склад. А.М>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим.
И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель".
А.М>>>но его придется пересчитывать в любом случае, где бы он не хранился. G>>Да, только в твоем случае надо будет пересчитывать все остатки после даты изменения, а это мягко говоря дохорена окажется. А.М>>>Можно конечно и не хранить,но тогда придется все время пересчитывать, чтобы узнать остатки. G>>Можно заставить БД пересчитывать, а самому не париться, но при этом не получится "доменная модель" как ты её описал. А.М>Но таки пересчитывать придется в любом случае, и мне кажется получение остатков более частая операция чем исправление проводки А.М>сделанной в прошлом году.
Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго.
G>>>>3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной. А.М>>>Добавляем класс/таблицу "Накладная" и ссылки на "проводки". G>>Именно так получаются самые ужасные бухгалтерские программы — добавлением таблиц на каждую необходимость. А.М>А вы что предлагаете?
Я предлагаю не плодить сложность.
А.М>Если необходимость есть, надо добавлять, нет -- не добавлять.
А вот тут ты неправ. Например накладные нужны в случае отгрузки товара, а для случаев инвентаризации и переучета никаких накладных не будет, будут другие документы. А ты кроме количества разных сущностей еще и плодишь частные случаи, что в совокупности создает геометрический рост сложности решения.
Самое неприятное типы документов меняются быстрее чем средний программист успевает из реализовывать с твоим подходом.
А.М>Или вы предпочитаете модель водопада?
А причем тут водопада?
G>>>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>>И как эти псевдоотгрузки отличать от обычных отгрузок? А.М>По значению поля "Кому отгружаем".
Про частные случаи написал выше.
А.М>>>Реляционные БД -- это только один из способов хранить данные. Есть и другие варианты. G>>Сделай бухгалтерию на нереляционной БД, мы посмотрим. А.М>Почему нет? NoSQL пока может еще и сыроваты, но прогресс не стоит на месте.
Ты поверил в "серебряную пулю NoSQL" ?
Лучше изучай Olap — больше пользы будет.
Задачи учета — это чаще всего задачи многомерного анализа данных. По сути есть две категории атрибутов "меры" (measure) и "измерения" (dimensions).
Меры — это остатки и обороты (может быть как в "деньгах", так и в "количестве"), измерения — все остальное — периоды времени, бухгалтерские счета, документы, контрагенты, товары, категории товаров (может быть иерархические), склады... продолжать можно долго.
Например бухгалтерский баланс — выборка мер по определенным измерениям с агрегацией по ним за период (квартал).
Если заранее не предусмотреть единую схему для измерений, то сложность сопровождения будет расти геометрически от количества измерений. А если еще вводить частные случаи, то агрегация данных по измерениям станет проблематичной.
Всего возможных выборок будет 2^N по количеству измерений. С реляционными субд проще, там можно генерить запросы с нужными выборками, но в РСУБД медленно делается агрегация. Для оптимизации можно делать агрегацию по некоторым измерениям заранее.
Для NoSQL решения, где нельзя сделать произвольную выборку, придется ручками запихивать все выборки.
А в идеале всю эту работу надо возложить на умный Olap.
Re[7]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.
... << RSDN@Home 1.2.0 alpha 4 rev. 1474 on Windows 7 6.1.7600.0>>
Здравствуйте, gandjustas, Вы писали:
А.М>>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим. G>И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель".
Унификация тут не получается, потому что в общем случае источник и получатель -- это не всегда склад. Зато в случае, если надо указать кроме склада еще, допустим, сектор в котором хранится этот товар, это будет сделать проще.
G>Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго.
В данном случае весь пересчет заключается лишь в сложении двух чисел. Тут конечно тоже можно умудриться сделать медленно и с ошибками, но с таким подходом никакая база не поможет.
А.М>>Если необходимость есть, надо добавлять, нет -- не добавлять. G>А вот тут ты неправ. Например накладные нужны в случае отгрузки товара, а для случаев инвентаризации и переучета никаких накладных не будет, будут другие документы. А ты кроме количества разных сущностей еще и плодишь частные случаи, что в совокупности создает геометрический рост сложности решения. G>Самое неприятное типы документов меняются быстрее чем средний программист успевает из реализовывать с твоим подходом.
Не нравится название "накладная", можно назвать "складская транзакция" из которой уже и будут создаваться документы. Но если ее не создавать, то по какому признаку вы предлагаете выбирать проводки для конкретной накладной, по дате?
А.М>>Или вы предпочитаете модель водопада? G>А причем тут водопада?
Из ваших слов я понял что вы предлагаете изменения в систему после этапа проектирования не вносить. Это модель водопада, хотя в большинстве случаев итеративный подход удобнее.
G>>>>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>>>И как эти псевдоотгрузки отличать от обычных отгрузок? А.М>>По значению поля "Кому отгружаем". G>Про частные случаи написал выше.
А можно конкретнее? Как добавление такого вида (направления) отгрузки как "списание" геометрически увеличивает сложность?
G>Задачи учета — это чаще всего задачи многомерного анализа данных. По сути есть две категории атрибутов "меры" (measure) и "измерения" (dimensions).
Нет, задача учета -- это именно задача учета, то-есть сохранения информации (в данном случае о движении товара). А задача анализа -- это задача обработки имеющихся данных без их модификации. Тут речь идет именно об учете, а потом берем таблицу проводок и анализируем вдоль и поперек, получаем статистику, генерируем документы и т.д.
G>А в идеале всю эту работу надо возложить на умный Olap.
Вот анализ можно и на умный Olap возложить например, если объемы и сложность анализа этого потребуют.
Re[3]: Задачка: модель данных для склада с версионностью
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
AVK>В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.
Я тоже так считаю, но топикстартер указал что надо ограничить объем базы, поэтому надо как-то выкручиваться.
Хотя я сделал пример, получилось чуть больше гига на 10 миллионов проводок, вместе с индексированными вьюхами. На SQL Server 2008r2 express, с 10 гб базой хватит на очень долго.
Re[4]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>>>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
AVK>>В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.
G>Я тоже так считаю
Хм, как тогда понимать выделенное?
G>, но топикстартер указал что надо ограничить объем базы, поэтому надо как-то выкручиваться.
Не понимаю. Зачем для ограничения объема базы добавлять агрегаты? Результат то будет прямо противоположный, срезы по проводкам нередко имеют размер, сходный с размером самих проводок.
... << RSDN@Home 1.2.0 alpha 4 rev. 1474 on Windows 7 6.1.7600.0>>
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, gandjustas, Вы писали:
А.М>>>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим. G>>И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель". А.М>Унификация тут не получается, потому что в общем случае источник и получатель -- это не всегда склад. Зато в случае, если надо указать кроме склада еще, допустим, сектор в котором хранится этот товар, это будет сделать проще.
Получается унификация, если подходить не с точки зрения "доменной модели", а с точки зрения многомерного анализа (читай бухучета).
G>>Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго. А.М>В данном случае весь пересчет заключается лишь в сложении двух чисел. Тут конечно тоже можно умудриться сделать медленно и с ошибками, но с таким подходом никакая база не поможет.
Поможет, потому что база задает пересчет декларативно. Ты просто пишешь запрос, который агрегирует данные за период и с помощью пары магических движений получаешь материализованную вьюху. После этого сама база заботится о сложении чисел.
А.М>>>Если необходимость есть, надо добавлять, нет -- не добавлять. G>>А вот тут ты неправ. Например накладные нужны в случае отгрузки товара, а для случаев инвентаризации и переучета никаких накладных не будет, будут другие документы. А ты кроме количества разных сущностей еще и плодишь частные случаи, что в совокупности создает геометрический рост сложности решения. G>>Самое неприятное типы документов меняются быстрее чем средний программист успевает из реализовывать с твоим подходом. А.М>Не нравится название "накладная", можно назвать "складская транзакция" из которой уже и будут создаваться документы. Но если ее не создавать, то по какому признаку вы предлагаете выбирать проводки для конкретной накладной, по дате?
Ты застрял в "доменной модели". Не в названиях дело, а в способах работы и представления в БД.
А.М>>>Или вы предпочитаете модель водопада? G>>А причем тут водопада? А.М>Из ваших слов я понял что вы предлагаете изменения в систему после этапа проектирования не вносить. Это модель водопада, хотя в большинстве случаев итеративный подход удобнее.
G>>>>>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>>>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>>>>И как эти псевдоотгрузки отличать от обычных отгрузок? А.М>>>По значению поля "Кому отгружаем". G>>Про частные случаи написал выше. А.М>А можно конкретнее? Как добавление такого вида (направления) отгрузки как "списание" геометрически увеличивает сложность?
Например у тебя есть N выборок, которые анализируют отгрузки, при появлении частного случая (псевдоотргузка) надо поменять все или почти все запросы. При этом еще добавится K запросов для этого частного случая. Если появляется еще один частный случай в этой же плоскости, то надо будет менять часть из N+K запросов и добавить еще M, которые при появлении следующего частного случая...
G>>Задачи учета — это чаще всего задачи многомерного анализа данных. По сути есть две категории атрибутов "меры" (measure) и "измерения" (dimensions). А.М>Нет, задача учета -- это именно задача учета, то-есть сохранения информации (в данном случае о движении товара). А задача анализа -- это задача обработки имеющихся данных без их модификации. Тут речь идет именно об учете, а потом берем таблицу проводок и анализируем вдоль и поперек, получаем статистику, генерируем документы и т.д.
Ну сложность кода анализа будет напрямую зависеть от построения схемы данных.
При этом сама суть учета меняется медленно, 500 лет до нашей эры придумали двойную бухгалтерскую запись и живет она до сих пор, а вот анализ меняется очень быстро, вчера нужно было только баланс, а сегодня — определять потребительскую корзину и строить план закупок.
Re[5]: Задачка: модель данных для склада с версионностью
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>>>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
AVK>>>В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.
G>>Я тоже так считаю
AVK>Хм, как тогда понимать выделенное?
Потому что фирма ведет какую-то деятельность на момент внедрения ПО, и поэтому вначале будут проводки, которые фиксируют остатки на начало работы программы (1).
G>>, но топикстартер указал что надо ограничить объем базы, поэтому надо как-то выкручиваться.
AVK>Не понимаю.
Действительно.
AVK>Зачем для ограничения объема базы добавлять агрегаты? Результат то будет прямо противоположный, срезы по проводкам нередко имеют размер, сходный с размером самих проводок.
Когда наступает время Ч и объем таблицы проводок превышает критическую величину, тогда берутся первые N записей проводок, отсортированные по возрастанию даты и группируются по "счетам". Потом они записываются вместо (1).
Re[6]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, gandjustas, Вы писали:
G>>>>>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
AVK>>>>В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.
G>>>Я тоже так считаю
AVK>>Хм, как тогда понимать выделенное? G>Потому что фирма ведет какую-то деятельность на момент внедрения ПО, и поэтому вначале будут проводки, которые фиксируют остатки на начало работы программы (1).
Я понял, ввела в заблуждение фраза про остатки на начало периода. Тут имелся ввиду период указанный топикстартером
R>6. Прошедшие операции следует хранить не более 1 года.
Re[7]: Задачка: модель данных для склада с версионностью
Здравствуйте, Ziaw, Вы писали:
Z>Картинками можно освоить любой объем. А вообще это не проблема если держать их в стримах, размер стримов не идет в счет 4Гб.
А стримы express версией поддерживаются?
... << RSDN@Home 1.2.0 alpha 4 rev. 1474 on Windows 7 6.1.7600.0>>
Здравствуйте, Ziaw, Вы писали:
R>>Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.
Z>Забить проводками 4ГБ надо сильно постараться.
10 в 2008 R2
Re[9]: Задачка: модель данных для склада с версионностью
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ziaw, Вы писали:
Z>>Картинками можно освоить любой объем. А вообще это не проблема если держать их в стримах, размер стримов не идет в счет 4Гб.
AVK>А стримы express версией поддерживаются?
Здравствуйте, AndrewVK, Вы писали:
Z>>Картинками можно освоить любой объем. А вообще это не проблема если держать их в стримах, размер стримов не идет в счет 4Гб.
AVK>А стримы express версией поддерживаются?
Да. По крайней мере 2008.
Re[9]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, А.М, Вы писали:
А.М>>Здравствуйте, gandjustas, Вы писали:
А.М>>>>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим. G>>>И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель". А.М>>Унификация тут не получается, потому что в общем случае источник и получатель -- это не всегда склад. Зато в случае, если надо указать кроме склада еще, допустим, сектор в котором хранится этот товар, это будет сделать проще. G>Получается унификация, если подходить не с точки зрения "доменной модели", а с точки зрения многомерного анализа (читай бухучета).
И все-же где в БД вы будете сохранять место расположения товара на складе?
G>>>Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго. А.М>>В данном случае весь пересчет заключается лишь в сложении двух чисел. Тут конечно тоже можно умудриться сделать медленно и с ошибками, но с таким подходом никакая база не поможет. G>Поможет, потому что база задает пересчет декларативно. Ты просто пишешь запрос, который агрегирует данные за период и с помощью пары магических движений получаешь материализованную вьюху. После этого сама база заботится о сложении чисел.
Неубедительно. Декларативный запрос написать ничуть не проще, чем просто сложить А+Б, что и требуется в данном случае.
А.М>>>>Если необходимость есть, надо добавлять, нет -- не добавлять. G>>>А вот тут ты неправ. Например накладные нужны в случае отгрузки товара, а для случаев инвентаризации и переучета никаких накладных не будет, будут другие документы. А ты кроме количества разных сущностей еще и плодишь частные случаи, что в совокупности создает геометрический рост сложности решения. G>>>Самое неприятное типы документов меняются быстрее чем средний программист успевает из реализовывать с твоим подходом. А.М>>Не нравится название "накладная", можно назвать "складская транзакция" из которой уже и будут создаваться документы. Но если ее не создавать, то по какому признаку вы предлагаете выбирать проводки для конкретной накладной, по дате? G>Ты застрял в "доменной модели". Не в названиях дело, а в способах работы и представления в БД.
Ваша мысль неясна.
А.М>>>>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>>>>>И как эти псевдоотгрузки отличать от обычных отгрузок? А.М>>>>По значению поля "Кому отгружаем". G>>>Про частные случаи написал выше. А.М>>А можно конкретнее? Как добавление такого вида (направления) отгрузки как "списание" геометрически увеличивает сложность? G>Например у тебя есть N выборок, которые анализируют отгрузки, при появлении частного случая (псевдоотргузка) надо поменять все или почти все запросы. При этом еще добавится K запросов для этого частного случая. Если появляется еще один частный случай в этой же плоскости, то надо будет менять часть из N+K запросов и добавить еще M, которые при появлении следующего частного случая...
Если у меня есть N выборок, которые анализируют отгрузки, то выбираются эти отгрузки по некоторым надобам признаков и добавление отгрузок с другими признаками на это не повлияет. Если-же они анализируют отгрузки вообще, то и псевдоотгрузки вписываются в этот общий случай.
И вы таки не ответили, как-же по вашему можно добавить списания, ничего не добавив в БД.
G>Ну сложность кода анализа будет напрямую зависеть от построения схемы данных. G>При этом сама суть учета меняется медленно, 500 лет до нашей эры придумали двойную бухгалтерскую запись и живет она до сих пор, а вот анализ меняется очень быстро, вчера нужно было только баланс, а сегодня — определять потребительскую корзину и строить план закупок.
Вы хотите сказать, что существует некая каноническая реляционная модель данных бухгалтерского учета, покрывающая подавляющее большинство случаев учета чего угодно? Не поделитесь ссылкой на описание этой модели?
Re[10]: Задачка: модель данных для склада с версионностью
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, А.М, Вы писали:
А.М>>>Здравствуйте, gandjustas, Вы писали:
А.М>>>>>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим. G>>>>И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель". А.М>>>Унификация тут не получается, потому что в общем случае источник и получатель -- это не всегда склад. Зато в случае, если надо указать кроме склада еще, допустим, сектор в котором хранится этот товар, это будет сделать проще. G>>Получается унификация, если подходить не с точки зрения "доменной модели", а с точки зрения многомерного анализа (читай бухучета). А.М>И все-же где в БД вы будете сохранять место расположения товара на складе?
Сделаю таблицу с тремя полями: id_товара, id_склада, место
G>>>>Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго. А.М>>>В данном случае весь пересчет заключается лишь в сложении двух чисел. Тут конечно тоже можно умудриться сделать медленно и с ошибками, но с таким подходом никакая база не поможет. G>>Поможет, потому что база задает пересчет декларативно. Ты просто пишешь запрос, который агрегирует данные за период и с помощью пары магических движений получаешь материализованную вьюху. После этого сама база заботится о сложении чисел. А.М>Неубедительно. Декларативный запрос написать ничуть не проще, чем просто сложить А+Б, что и требуется в данном случае.
Нет, ты забыл что надо: 1) прочитать А 2)Прибавить Б 3)записать сумму 4)повторить тоже самое для другого А (ты же не надеешься что это будет в одном месте) 5)Вызвать этот код во всех необходимых местах (а их еще найти надо)
Сравни это с написанием одного запроса select ... sum(amount) from entries group by date . и все, больше ниче не надо.
Вообще запросы гораздо удобнее любого императивного кода, потому что они максимально декларативны, тебе не надо заботится почему произошли изменения было это добавление, изменение или удаление, не надо париться с транзакциями. Если ошибешься в запросе, то он не порушит данные, а просто отвалится при создании view (то есть еще в design time).
А.М>>>>>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>>>>>>И как эти псевдоотгрузки отличать от обычных отгрузок? А.М>>>>>По значению поля "Кому отгружаем". G>>>>Про частные случаи написал выше. А.М>>>А можно конкретнее? Как добавление такого вида (направления) отгрузки как "списание" геометрически увеличивает сложность? G>>Например у тебя есть N выборок, которые анализируют отгрузки, при появлении частного случая (псевдоотргузка) надо поменять все или почти все запросы. При этом еще добавится K запросов для этого частного случая. Если появляется еще один частный случай в этой же плоскости, то надо будет менять часть из N+K запросов и добавить еще M, которые при появлении следующего частного случая... А.М>Если у меня есть N выборок, которые анализируют отгрузки, то выбираются эти отгрузки по некоторым надобам признаков и добавление отгрузок с другими признаками на это не повлияет. Если-же они анализируют отгрузки вообще, то и псевдоотгрузки вписываются в этот общий случай.
Да ну.. Ну были у тебя запросы, который собирает отгрузки по клиентам, поставщикам, накладным (3 штука), тут у тебя появляется "псевдоотгрузка", которая обозначает списание и тебе надо поправить 3 запроса + написать как минимум один чтобы показывать списания. А потому у тебя добавляется еще одна псевдоотгрузка, и ты снова вынужден минимум 3 запроса править.
Но ты можешь попытаться ортогонализировать такое и ввести отдельные поля для каждого типа, тогда у тебя таблица проводок быстро наполнится полями, большая часть из которых — null.
А.М>И вы таки не ответили, как-же по вашему можно добавить списания, ничего не добавив в БД.
А я разве говорил что такое можно? Я говорил что можно это сделать не добавляя "частные случаи".
G>>Ну сложность кода анализа будет напрямую зависеть от построения схемы данных. G>>При этом сама суть учета меняется медленно, 500 лет до нашей эры придумали двойную бухгалтерскую запись и живет она до сих пор, а вот анализ меняется очень быстро, вчера нужно было только баланс, а сегодня — определять потребительскую корзину и строить план закупок. А.М>Вы хотите сказать, что существует некая каноническая реляционная модель данных бухгалтерского учета, покрывающая подавляющее большинство случаев учета чего угодно? Не поделитесь ссылкой на описание этой модели? http://rsdn.ru/article/db/RDBMS.xml
Здравствуйте, ronaldo9, Вы писали:
R>Здравствуйте.
R>У меня вопрос по проектированию модели данных для складов. Общие требования к разрабатываемой системе такие: R>1. Есть несколько складов. На складе располагаются товары. R>2. Есть операции приемки товара на склад, перемещения на другой склад и списания со склада. R>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год) R>4. Необходимо хранить данные по прошедшим операциям. R>5. Необходима возможность отмены и изменения прошедшей операции приемки/перемещения/списания. R>6. Прошедшие операции следует хранить не более 1 года.
R>Какой подход избрать для проектирования модели данных?
R>У меня в голове сейчас 3 варианта.
R>1 вариант. Не хранить, сколько товара было на складе в каждый конкретный момент. Хранить только операции, например:
R>
R>Товар Склад Кол-во Дата Тип операции
R>----------------------------------------------------
R>Телевизор С1 +8 март Приход
R>Телевизор С1 -1 апрель Расход
R>Телевизор С2 +1 апрель Приход
R>
R>Тогда мы можем агрегировать эти операции по складу и товару и получить количество товара на заданную дату. Легко отменить операцию — просто не учитывать ее при агрегировании. Однако старые операции должны храниться только 1 год, а затем удаляться, значит мы потеряем данные. Кроме того, чтобы получить состояние складов на сегодня, придется выгружать всю таблицу операций в память, чтобы провести агрегирование — теряем в производительности.
R>2 вариант. Хранить и операции, и состояние товара на складе. Причем состояние товара — это версионные данные. Например:
R>
R>Товар Склад Кол-во Дата
R>-----------------------------------
R>Телевизор С1 8 март
R>Телевизор С1 7 апрель
R>Телевизор С2 1 апрель
R>
R>Теперь мы можем удалять старые операции и даже старые записи из таблицы состояние складов. Однако размер БД увеличивается и появляются сложности с отменой прошлых операции. Чтобы отменить операцию, нужно провести цепочку изменений в таблице состояния склада — ведь изменятся все последующие записи, связанные с данным товаром.
R>Вероятно, имеет право на жизнь 3 вариант, который является комбинацией 1 и 2 вариантов. В нем мы заводим табличку "базового" состояния складов, которое было до совершения первой неудаленной операции. Тогда, при удалении устаревших операций, мы применяем их к "базовому" состоянию складов. А состояние складов за определенную дату получается путем объединения "базового" состояния и операций до этой даты.
R>А какое Ваше мнение, господа? R>Заранее всем спасибо.
две таблички — перемещение
перемещение — товар /откуда/куда/сколько
текущее состояние — товар/склад/кол-во
и больше ничего не надо. ну можно еще "срезы" хранить для скорости
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, fleandr, Вы писали:
F>две таблички — перемещение F>перемещение — товар /откуда/куда/сколько F>текущее состояние — товар/склад/кол-во
F>и больше ничего не надо. ну можно еще "срезы" хранить для скорости
еще когда забыл в перемещении ну и айдишники есстно
Re[3]: Задачка: модель данных для склада с версионностью
Я делаю такую же вещь, для собственных нужд.
Сделал по аналогии с бух учетом.
Баланс — активы=пассивы (обязательство+(кпитал)). Капитала пока нет.
У меня есть пока 2 счета активный и пассивный. Склад — активный, движение — пассивный. Пока только два счета, потом думаю добавится еще.
Есть бух. записи (жарг. проводки).
Приход товара: Дб Склад — Кр Движение
Продажа товара: Кр Склад — Дб Движение
Возврат поставщику: Кр Склад — Дб Движение
Возврат от покупателя: Дб Склад — Кр движение
Баланс отражает всегда наличие всего текущего товара. Пока два счета, то конечное сальдо по складу отражает наличие товара на складе. Потом возможно еще будет счет "ремонт".
на счет остатков необходимо проводить закрытие периода, и списывать остатки с прошлого периода на текущий. Чтобы узнать остаток за прошлый период, надо посмотреть начальное сальдо счета за текущий.
Счет делается на каждый тип товара.
Например "шампунь лореаль"(id =15) 10 шт, цена 60 руб/шт
Дт Склад — Кр Движение id=15, 10шт, цена 60 руб/шт
Если цены разные, то оформление идет в 2 бух записи.
Скоро возможно выложу код для оценки.
Opinions?
Re[4]: Задачка: модель данных для склада с версионностью
Здравствуйте, diez_p, Вы писали:
_>У меня есть пока 2 счета активный и пассивный. Склад — активный, движение — пассивный. Пока только два счета, потом думаю добавится еще. _>Есть бух. записи (жарг. проводки). _>Приход товара: Дб Склад — Кр Движение _>Продажа товара: Кр Склад — Дб Движение _>Возврат поставщику: Кр Склад — Дб Движение _>Возврат от покупателя: Дб Склад — Кр движение
Что-то тут не так. Счётов д.б. три, т.к. вижу отношения поставщик <--> склад и склад <--> покупатель. Соответственно, поставщик-покупатель-склад и есть счёта. Если совместить поставщика и покупателя в один счёт, то никакого смысла в наличии четырёх разных проводок нет, достаточно двух.
Здравствуйте, akasoft, Вы писали:
>сли совместить поставщика и покупателя в один счёт, то никакого смысла в наличии четырёх разных проводок нет, достаточно двух.
Да вы правы, спасибо, у меня закрадывалась мысль, что, что-то тут не то. Единственное это внутри счета может показать как ушли деньги, но для этого надо отдельный счет.
Буду думать
Re: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год) R>4. Необходимо хранить данные по прошедшим операциям.
Это называется temporal database. Некоторые СУБД (Oracle?) имеют готовые механизмы для этого.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, ronaldo9, Вы писали:
R>>Здравствуйте.
R>>У меня вопрос по проектированию модели данных для складов.
R>>А какое Ваше мнение, господа?
G>А почему не 1С?
Похоже кто-то хочет написать своё. Вообще было-бы неплохо иметь библиотеку 1С-подобных классов, но на шарпе... Интересно, есть что-нибудь подобное уже в готовом виде.
У вас тут разговор слепого с глухим. Ты совершенно правильно говоришь о координатах и значениях (измерениях и мерах, аналитиках и значениях, атрибутах и выборках и как там еще это можно обозвать), но как-то недостаточно явно, ибо оппонент очевидно не понимает, о чем речь. Вообще говоря, оба подхода плохи, но решения лучше либо не найдено, либо его вообще не существует.
RDBMS подход хорош только в первом приближении. В пределе заводим единую таблицу проводок, в которой у нас лежат все значения в разрезе по всем возможным координатам, в которой храним как 1) "реальные данные" (данные реальных счетов), т.е. как оно заводится "в документах", так и переносим — без агрегации или разбиения, — так и 2) разные "нереальные данные" (данные синтетических счетов) — разбиения и группировки, частичные остатки и прочую муть для нужд практического учета и быстрых отчетов. Конечно, прямые реальные остатки будут храниться верно и выбираться просто, но все агрегации и расчеты на основе агрегаций будет уже писать человек! Причем ладно бы это были только обороты за период, где ошибиться трудно. Это будут синтетические проводки по разным галочкам в карточке товара, в карточке контрагента и в шапке документа, которые, если там еще история завязана, может пересчитываться неадекватно, а уж если какое значение в отчете зависит от суммы/разницы таких вот значений, то там точно также легко наваять неверную формулу расчета — забыли что-то прибавить или вычесть, или еще хуже, обнаружили в конце концов, что на основе этих значений посчитать нельзя и нужны другие синтетические счета.
Что, наверное, хотел донести gandjustas, так это то, что если завязать "маршрут обсчета" значений на связи в доменной модели, то это будет гораздо хуже синтетических строк в мегатаблице, потому что требования к учету и выборкам меняются очень быстро и непредсказуемо — отражающая их модель должна будет постоянно меняться и усложняться, и когда наконец разработчик поймет, что он уже всласть наигрался в проектирование доменных моделей, что пользователи в них всё равно не шарят (ибо в процессе подгонки под нужное поведение смысл доменных объектов стал таким же далеким от реальности, как "кольцо" и "поле" в математике далеки от свадеб и лугов), и что на выходе-то от него требуется всего лишь правильное число... когда всё это поднадоест, свалочная мегатаблица покажется эталоном мудрости.
Здравствуйте, Poudy, Вы писали:
P>RDBMS подход хорош только в первом приближении. В пределе заводим единую таблицу проводок, в которой у нас лежат все значения в разрезе по всем возможным координатам, в которой храним как 1) "реальные данные" (данные реальных счетов), т.е. как оно заводится "в документах", так и переносим — без агрегации или разбиения, — так и 2) разные "нереальные данные" (данные синтетических счетов) — разбиения и группировки, частичные остатки и прочую муть для нужд практического учета и быстрых отчетов. Конечно, прямые реальные остатки будут храниться верно и выбираться просто, но все агрегации и расчеты на основе агрегаций будет уже писать человек! Причем ладно бы это были только обороты за период, где ошибиться трудно. Это будут синтетические проводки по разным галочкам в карточке товара, в карточке контрагента и в шапке документа, которые, если там еще история завязана, может пересчитываться неадекватно, а уж если какое значение в отчете зависит от суммы/разницы таких вот значений, то там точно также легко наваять неверную формулу расчета — забыли что-то прибавить или вычесть, или еще хуже, обнаружили в конце концов, что на основе этих значений посчитать нельзя и нужны другие синтетические счета.
Не надо смешивать все в одну кучу. Одно дело аналитически отчеты по проводкам (баланс и все такое), другое дело документооборот, который должен в идеале делаться отдельно от самой бухгалтерии и нужно иметь слой отображения документов на проводки.
Re[5]: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.
Мыши плакали, кололись, но все равно ели кактус. Почему не взять бесплатную СУБД с ограничениями в терабайты? Тот же postgresql.
Здравствуйте, А.М, Вы писали:
А.М>Почему нет? NoSQL пока может еще и сыроваты, но прогресс не стоит на месте.
А разве реализации nosql поддерживает ACID в полном объеме?
Здравствуйте, ronaldo9, Вы писали:
R>Здравствуйте.
R>У меня вопрос по проектированию модели данных для складов. Общие требования к разрабатываемой системе такие: R>1. Есть несколько складов. На складе располагаются товары. R>2. Есть операции приемки товара на склад, перемещения на другой склад и списания со склада. R>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год) R>4. Необходимо хранить данные по прошедшим операциям. R>5. Необходима возможность отмены и изменения прошедшей операции приемки/перемещения/списания. R>6. Прошедшие операции следует хранить не более 1 года.
R>Какой подход избрать для проектирования модели данных?
R>У меня в голове сейчас 3 варианта.
R>1 вариант. Не хранить, сколько товара было на складе в каждый конкретный момент. Хранить только операции, например:
R>Тогда мы можем агрегировать эти операции по складу и товару
1) Хранить только операции и агрегировать (например через индексированные/материализованные представления, ну или собственным велосипедом) тоже только операции, а не остатки (существенно меньше пересчета в случае отмены операции и по теории РБД более правильно)
2) операцию перемещения желательно хранить одним кортежем причем в той же таблице что и приход расход (проще расчеты и меньше возможных ошибок). Что-то типа Источник (склад или null если приход), Приёмник (склад или null если списание), Товар, Количество.
3) во временной таблице или где-то в слое бизнес логики возможно полезно будет хранить актуальные остатки на текущий момент (а интерфейс к этой таблице тот же что и для "прошлых состояний", просто текущее состояние будет отображаться гораздо быстрее, а я уверен именно его и будут запрашивать в 99% случаев)
4) если "не хранить операции старше года" жёсткое требование, тогда за давние периоды хранить только агрегаты. В этом случае скорее всего свой "велосипед" для агрегации придется делать или заменять старые движения агрегированными движениями прямо в рабочей таблице. Но я бы хранил всю историю.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Poudy, Вы писали:
P>>RDBMS подход хорош только в первом приближении. В пределе заводим единую таблицу проводок, в которой у нас лежат все значения в разрезе по всем возможным координатам, в которой храним как 1) "реальные данные" (данные реальных счетов), т.е. как оно заводится "в документах", так и переносим — без агрегации или разбиения, — так и 2) разные "нереальные данные" (данные синтетических счетов) — разбиения и группировки, частичные остатки и прочую муть для нужд практического учета и быстрых отчетов. Конечно, прямые реальные остатки будут храниться верно и выбираться просто, но все агрегации и расчеты на основе агрегаций будет уже писать человек! Причем ладно бы это были только обороты за период, где ошибиться трудно. Это будут синтетические проводки по разным галочкам в карточке товара, в карточке контрагента и в шапке документа, которые, если там еще история завязана, может пересчитываться неадекватно, а уж если какое значение в отчете зависит от суммы/разницы таких вот значений, то там точно также легко наваять неверную формулу расчета — забыли что-то прибавить или вычесть, или еще хуже, обнаружили в конце концов, что на основе этих значений посчитать нельзя и нужны другие синтетические счета.
G>Не надо смешивать все в одну кучу. Одно дело аналитически отчеты по проводкам (баланс и все такое), другое дело документооборот, который должен в идеале делаться отдельно от самой бухгалтерии и нужно иметь слой отображения документов на проводки.
Сорри за задержку — почему-то на почту не ходят ответы. Я полностью согласен — не надо ничего смешивать. Бухгалтерия тут не при чем, я говорил о складских проводках. Ведь строки документов склада тоже не надо мешать в кучу с остатками, а иметь отдельные складские проводки для склада, правда же? Да ты и сам об этом писал, что я. Не знаю, мне кажется я всё понятно очень написал, откуда ты вычитал баланс не знаю... Покупайте облигации обязательного займа!
Здравствуйте, Poudy, Вы писали:
P>Бухгалтерия тут не при чем, я говорил о складских проводках.
А склад остатки уже не является объектом бухгалтерского учета?
P>Ведь строки документов склада тоже не надо мешать в кучу с остатками, а иметь отдельные складские проводки для склада, правда же?
Чето не понял что от чего предполагается отделять и зачем.
Re: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>У меня вопрос по проектированию модели данных для складов. Общие требования к разрабатываемой системе такие: R>1. Есть несколько складов. На складе располагаются товары. R>2. Есть операции приемки товара на склад, перемещения на другой склад и списания со склада. R>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год) R>4. Необходимо хранить данные по прошедшим операциям. R>5. Необходима возможность отмены и изменения прошедшей операции приемки/перемещения/списания. R>6. Прошедшие операции следует хранить не более 1 года.
1. Взять готовое решение (например, 1С); слегка доработать напильником, если надо.
2. Сделать хранилище данных (ХД), в которое ежедневно (чаще или реже, зависит от ваших необходимостей) загружать сделанные изменения. ХД как раз и будет источником исторических изменений.
3. Из ХД делать аналитику с помощью какого-нибудь OLAP'а и/или репортингового тулза.
Многие и рады были бы испытать когнитивный диссонанс, но нечем.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Poudy, Вы писали:
P>>Бухгалтерия тут не при чем, я говорил о складских проводках. G>А склад остатки уже не является объектом бухгалтерского учета?
да при тут этот вопрос? не видел WMS без бухгалтерии?
P>>Ведь строки документов склада тоже не надо мешать в кучу с остатками, а иметь отдельные складские проводки для склада, правда же? G>Чето не понял что от чего предполагается отделять и зачем.
складской учет в общем случае это не бухгалтерия и у него должны быть свои проводки для остатков. можно себе считать, что они всё равно концептуально бухгалтерские. но для штрихкодированного или продвинутого серийного учета (как у фармацевтов) детализация будет выше, чем нужно для бухучета. также реально, когда со склада в складской списание идет реальных партий или даже позиций товара, а по складу в бухгалтерской — какое-нибудь lifo или среднее (по деньгам) для единой номенклатуры. Тут спорить не о чем.
