Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

G>>>>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.

AVK>>>В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.

G>>Я тоже так считаю

AVK>Хм, как тогда понимать выделенное?
Потому что фирма ведет какую-то деятельность на момент внедрения ПО, и поэтому вначале будут проводки, которые фиксируют остатки на начало работы программы (1).

G>>, но топикстартер указал что надо ограничить объем базы, поэтому надо как-то выкручиваться.

AVK>Не понимаю.
Действительно.

AVK>Зачем для ограничения объема базы добавлять агрегаты? Результат то будет прямо противоположный, срезы по проводкам нередко имеют размер, сходный с размером самих проводок.

Когда наступает время Ч и объем таблицы проводок превышает критическую величину, тогда берутся первые N записей проводок, отсортированные по возрастанию даты и группируются по "счетам". Потом они записываются вместо (1).

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, AndrewVK, Вы писали:

AVK>>Здравствуйте, gandjustas, Вы писали:

G>>>>>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.

AVK>>>>В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.

G>>>Я тоже так считаю

AVK>>Хм, как тогда понимать выделенное?
G>Потому что фирма ведет какую-то деятельность на момент внедрения ПО, и поэтому вначале будут проводки, которые фиксируют остатки на начало работы программы (1).

Я понял, ввела в заблуждение фраза про остатки на начало периода. Тут имелся ввиду период указанный топикстартером

R>6. Прошедшие операции следует хранить не более 1 года.

Здравствуйте, AndrewVK, Вы писали:

AVK>+1. Но если туда пихать каталог товаров с картинками и описаниями, то таки можно.

Картинками можно освоить любой объем. А вообще это не проблема если держать их в стримах, размер стримов не идет в счет 4Гб.

Здравствуйте, Ziaw, Вы писали:

Z>Картинками можно освоить любой объем. А вообще это не проблема если держать их в стримах, размер стримов не идет в счет 4Гб.

А стримы express версией поддерживаются?

Здравствуйте, Ziaw, Вы писали:

R>>Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.

Z>Забить проводками 4ГБ надо сильно постараться.

10 в 2008 R2

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Ziaw, Вы писали:

Z>>Картинками можно освоить любой объем. А вообще это не проблема если держать их в стримах, размер стримов не идет в счет 4Гб.

AVK>А стримы express версией поддерживаются?

Да. Вот здесь http://msdn.microsoft.com/en-us/library/cc645993.aspx можно убедиться — в разделе Programmability.
.

Здравствуйте, AndrewVK, Вы писали:

Z>>Картинками можно освоить любой объем. А вообще это не проблема если держать их в стримах, размер стримов не идет в счет 4Гб.

AVK>А стримы express версией поддерживаются?

Да. По крайней мере 2008.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, А.М, Вы писали:

А.М>>Здравствуйте, gandjustas, Вы писали:

А.М>>>>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим.
G>>>И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель".
А.М>>Унификация тут не получается, потому что в общем случае источник и получатель -- это не всегда склад. Зато в случае, если надо указать кроме склада еще, допустим, сектор в котором хранится этот товар, это будет сделать проще.
G>Получается унификация, если подходить не с точки зрения "доменной модели", а с точки зрения многомерного анализа (читай бухучета).
И все-же где в БД вы будете сохранять место расположения товара на складе?

G>>>Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго.
А.М>>В данном случае весь пересчет заключается лишь в сложении двух чисел. Тут конечно тоже можно умудриться сделать медленно и с ошибками, но с таким подходом никакая база не поможет.
G>Поможет, потому что база задает пересчет декларативно. Ты просто пишешь запрос, который агрегирует данные за период и с помощью пары магических движений получаешь материализованную вьюху. После этого сама база заботится о сложении чисел.
Неубедительно. Декларативный запрос написать ничуть не проще, чем просто сложить А+Б, что и требуется в данном случае.

А.М>>>>Если необходимость есть, надо добавлять, нет -- не добавлять.
G>>>А вот тут ты неправ. Например накладные нужны в случае отгрузки товара, а для случаев инвентаризации и переучета никаких накладных не будет, будут другие документы. А ты кроме количества разных сущностей еще и плодишь частные случаи, что в совокупности создает геометрический рост сложности решения.
G>>>Самое неприятное типы документов меняются быстрее чем средний программист успевает из реализовывать с твоим подходом.
А.М>>Не нравится название "накладная", можно назвать "складская транзакция" из которой уже и будут создаваться документы. Но если ее не создавать, то по какому признаку вы предлагаете выбирать проводки для конкретной накладной, по дате?
G>Ты застрял в "доменной модели". Не в названиях дело, а в способах работы и представления в БД.
Ваша мысль неясна.

А.М>>>>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход.
G>>>>>И как эти псевдоотгрузки отличать от обычных отгрузок?
А.М>>>>По значению поля "Кому отгружаем".
G>>>Про частные случаи написал выше.
А.М>>А можно конкретнее? Как добавление такого вида (направления) отгрузки как "списание" геометрически увеличивает сложность?
G>Например у тебя есть N выборок, которые анализируют отгрузки, при появлении частного случая (псевдоотргузка) надо поменять все или почти все запросы. При этом еще добавится K запросов для этого частного случая. Если появляется еще один частный случай в этой же плоскости, то надо будет менять часть из N+K запросов и добавить еще M, которые при появлении следующего частного случая...
Если у меня есть N выборок, которые анализируют отгрузки, то выбираются эти отгрузки по некоторым надобам признаков и добавление отгрузок с другими признаками на это не повлияет. Если-же они анализируют отгрузки вообще, то и псевдоотгрузки вписываются в этот общий случай.
И вы таки не ответили, как-же по вашему можно добавить списания, ничего не добавив в БД.

G>Ну сложность кода анализа будет напрямую зависеть от построения схемы данных.
G>При этом сама суть учета меняется медленно, 500 лет до нашей эры придумали двойную бухгалтерскую запись и живет она до сих пор, а вот анализ меняется очень быстро, вчера нужно было только баланс, а сегодня — определять потребительскую корзину и строить план закупок.
Вы хотите сказать, что существует некая каноническая реляционная модель данных бухгалтерского учета, покрывающая подавляющее большинство случаев учета чего угодно? Не поделитесь ссылкой на описание этой модели?

Здравствуйте, А.М, Вы писали:

А.М>Здравствуйте, 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>Заранее всем спасибо.

две таблички — перемещение
перемещение — товар /откуда/куда/сколько
текущее состояние — товар/склад/кол-во

и больше ничего не надо. ну можно еще "срезы" хранить для скорости

Здравствуйте, fleandr, Вы писали:

F>две таблички — перемещение
F>перемещение — товар /откуда/куда/сколько
F>текущее состояние — товар/склад/кол-во

F>и больше ничего не надо. ну можно еще "срезы" хранить для скорости

еще когда забыл в перемещении ну и айдишники есстно

Я делаю такую же вещь, для собственных нужд.
Сделал по аналогии с бух учетом.
Баланс — активы=пассивы (обязательство+(кпитал)). Капитала пока нет.
У меня есть пока 2 счета активный и пассивный. Склад — активный, движение — пассивный. Пока только два счета, потом думаю добавится еще.
Есть бух. записи (жарг. проводки).

Приход товара: Дб Склад — Кр Движение

Продажа товара: Кр Склад — Дб Движение

Возврат поставщику: Кр Склад — Дб Движение

Возврат от покупателя: Дб Склад — Кр движение

Баланс отражает всегда наличие всего текущего товара. Пока два счета, то конечное сальдо по складу отражает наличие товара на складе. Потом возможно еще будет счет "ремонт".
на счет остатков необходимо проводить закрытие периода, и списывать остатки с прошлого периода на текущий. Чтобы узнать остаток за прошлый период, надо посмотреть начальное сальдо счета за текущий.
Счет делается на каждый тип товара.
Например "шампунь лореаль"(id =15) 10 шт, цена 60 руб/шт
Дт Склад — Кр Движение id=15, 10шт, цена 60 руб/шт
Если цены разные, то оформление идет в 2 бух записи.
Скоро возможно выложу код для оценки.
Opinions?

Здравствуйте, diez_p, Вы писали:

_>Opinions?

Честно говоря нихрена не понятно.

Здравствуйте, diez_p, Вы писали:

_>У меня есть пока 2 счета активный и пассивный. Склад — активный, движение — пассивный. Пока только два счета, потом думаю добавится еще.
_>Есть бух. записи (жарг. проводки).
_>

Приход товара: Дб Склад — Кр Движение
_>

Продажа товара: Кр Склад — Дб Движение
_>

Возврат поставщику: Кр Склад — Дб Движение
_>

Возврат от покупателя: Дб Склад — Кр движение

Что-то тут не так. Счётов д.б. три, т.к. вижу отношения поставщик <--> склад и склад <--> покупатель. Соответственно, поставщик-покупатель-склад и есть счёта. Если совместить поставщика и покупателя в один счёт, то никакого смысла в наличии четырёх разных проводок нет, достаточно двух.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>> SQL Express 2005

Здравствуйте, akasoft, Вы писали:

>сли совместить поставщика и покупателя в один счёт, то никакого смысла в наличии четырёх разных проводок нет, достаточно двух.

Да вы правы, спасибо, у меня закрадывалась мысль, что, что-то тут не то. Единственное это внутри счета может показать как ушли деньги, но для этого надо отдельный счет.
Буду думать

Здравствуйте, ronaldo9, Вы писали:

R>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год)
R>4. Необходимо хранить данные по прошедшим операциям.

Это называется temporal database. Некоторые СУБД (Oracle?) имеют готовые механизмы для этого.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, ronaldo9, Вы писали:

R>>Здравствуйте.

R>>У меня вопрос по проектированию модели данных для складов.

R>>А какое Ваше мнение, господа?

G>А почему не 1С?
Похоже кто-то хочет написать своё. Вообще было-бы неплохо иметь библиотеку 1С-подобных классов, но на шарпе... Интересно, есть что-нибудь подобное уже в готовом виде.

У вас тут разговор слепого с глухим. Ты совершенно правильно говоришь о координатах и значениях (измерениях и мерах, аналитиках и значениях, атрибутах и выборках и как там еще это можно обозвать), но как-то недостаточно явно, ибо оппонент очевидно не понимает, о чем речь. Вообще говоря, оба подхода плохи, но решения лучше либо не найдено, либо его вообще не существует.

RDBMS подход хорош только в первом приближении. В пределе заводим единую таблицу проводок, в которой у нас лежат все значения в разрезе по всем возможным координатам, в которой храним как 1) "реальные данные" (данные реальных счетов), т.е. как оно заводится "в документах", так и переносим — без агрегации или разбиения, — так и 2) разные "нереальные данные" (данные синтетических счетов) — разбиения и группировки, частичные остатки и прочую муть для нужд практического учета и быстрых отчетов. Конечно, прямые реальные остатки будут храниться верно и выбираться просто, но все агрегации и расчеты на основе агрегаций будет уже писать человек! Причем ладно бы это были только обороты за период, где ошибиться трудно. Это будут синтетические проводки по разным галочкам в карточке товара, в карточке контрагента и в шапке документа, которые, если там еще история завязана, может пересчитываться неадекватно, а уж если какое значение в отчете зависит от суммы/разницы таких вот значений, то там точно также легко наваять неверную формулу расчета — забыли что-то прибавить или вычесть, или еще хуже, обнаружили в конце концов, что на основе этих значений посчитать нельзя и нужны другие синтетические счета.

Что, наверное, хотел донести gandjustas, так это то, что если завязать "маршрут обсчета" значений на связи в доменной модели, то это будет гораздо хуже синтетических строк в мегатаблице, потому что требования к учету и выборкам меняются очень быстро и непредсказуемо — отражающая их модель должна будет постоянно меняться и усложняться, и когда наконец разработчик поймет, что он уже всласть наигрался в проектирование доменных моделей, что пользователи в них всё равно не шарят (ибо в процессе подгонки под нужное поведение смысл доменных объектов стал таким же далеким от реальности, как "кольцо" и "поле" в математике далеки от свадеб и лугов), и что на выходе-то от него требуется всего лишь правильное число... когда всё это поднадоест, свалочная мегатаблица покажется эталоном мудрости.

Здравствуйте, Poudy, Вы писали:

P>RDBMS подход хорош только в первом приближении. В пределе заводим единую таблицу проводок, в которой у нас лежат все значения в разрезе по всем возможным координатам, в которой храним как 1) "реальные данные" (данные реальных счетов), т.е. как оно заводится "в документах", так и переносим — без агрегации или разбиения, — так и 2) разные "нереальные данные" (данные синтетических счетов) — разбиения и группировки, частичные остатки и прочую муть для нужд практического учета и быстрых отчетов. Конечно, прямые реальные остатки будут храниться верно и выбираться просто, но все агрегации и расчеты на основе агрегаций будет уже писать человек! Причем ладно бы это были только обороты за период, где ошибиться трудно. Это будут синтетические проводки по разным галочкам в карточке товара, в карточке контрагента и в шапке документа, которые, если там еще история завязана, может пересчитываться неадекватно, а уж если какое значение в отчете зависит от суммы/разницы таких вот значений, то там точно также легко наваять неверную формулу расчета — забыли что-то прибавить или вычесть, или еще хуже, обнаружили в конце концов, что на основе этих значений посчитать нельзя и нужны другие синтетические счета.

Не надо смешивать все в одну кучу. Одно дело аналитически отчеты по проводкам (баланс и все такое), другое дело документооборот, который должен в идеале делаться отдельно от самой бухгалтерии и нужно иметь слой отображения документов на проводки.

Здравствуйте, ronaldo9, Вы писали:

R>Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.
Мыши плакали, кололись, но все равно ели кактус. Почему не взять бесплатную СУБД с ограничениями в терабайты? Тот же postgresql.