DogenЕсть мнение, что создание таблицы полупроводок (вместо общеупотребимой таблицы проводок с указанием Дт и Кт счетов и аналитик) позволит улучшить многие характеристики системы оперативного учета.

Например, очень примитивным станет расчет текущих остатков.Код упростится, скорость работы увеличится.

зато несколько увеличится занимаемый объем, за счет избыточных полей (как
минимум - ссылок на образующий документ-основание + служебная информация
на запись. но в целом этим, конечно, можно пренебречь, тем более, можно
сразу получить выигрыш - за счет компрессии индексов (справедливо
по отношению к Oracle - когда branch блоки содержат общий префикс, leaf блоки - содержат уникальный суфикс ключа индекса).

Dogen
Можно даже их считать каждый раз на лету и отказаться (может быть) от таблицы остатков на счетах.

эт вы батенька, совсем напрасно. остатки считать и хранить нужно.
только не на начало-конец каждого отчетного период, как это принято, а
на... дату изменения остатка, т.е. на даты
собственно операции. т.е. остаток имеет период
действия - с - по BEG_DATE (NOT NULL), END_DATE (NOT NULL) соотвественно.
индекс строить примерно так. ACCOUNT_NUM, END_DATE, BEG_DATE.
правда, тут есть небольшие проблемы с партицированием.

Dogen
Справедливо как для количественного, так и для денежного учета. И для бухгалтерских проводок в несколько планов счетов тоже.

я бы сказал - скорее более правильно. счета по дебету и кредиту
могут иметь или не иметь еще и валютную составляющую.

плюс
могут быть и такие зверские корреспонденции, как закрытие
долларового остатка по счету 62.1 евровым остатком по счету
62.2 на основании какого доп. соглашения или векселя
хитрого. не совсем верно методически, но всяко бывает.

плюс - к примеру
корреспонденция 10-60 в оборотке по 10-му счету количество
светить должна, равно как и сумму и цену (и даже партию, если
вы применяете что-либо, отличное от средневзвешенного
метода оценки запасов - LIFO, FIFO), а для 60-го счета - фиолетово,
достаточно и даже нужно одной записи, а не 20-ти по каждому
товару отдельно.

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

вообще странная поставновка вопроса. атомарная операция на
основании документа-основания - есть одна транзакция в понятии БД,
как и одна транзакция в понятии ФУ. кроме того, ничего не стоит
поставить общую проверку контроль дебита-кредита в пределах
документа основания на уровне проводочного API (в разрезе балансов,
разумеется).

Dogen
Кто-нибудь использовал на практике структуру данных, не опирающуюся на принцип двойной записи? Что понравилось, что нет?

постановка вопроса не верна ;))) скорее правильно так -
"на принцип отражения корреспонденции двух счетов в пределах
одной записи таблицы БД"

скажу проще - полупроводки - выигрывают практически по всем
критериям. в особенности по производительности.

дело в том, что UNION как таковой требует операцию SORT UNIQUE
а UNION ALL не позволяет делать результирующую выборку
с сортировкой по индексу, без применения промежуточного буфера
(операции SORT ORDER BY).
т.е. в случае двух полей-счетов невозможно пользователю быстро выдать
первые 20-ть записей оборотного баланса без необходимости
тотальной сортировки всей ведомости.

итого - рудимент два счета в пределах записи - в топку.
сам пользовал по молодости. глюкодром был страшный.
доходило даже до кеширования проводок на стороне клиента.
аж вспоминать страшно ;)))

LSVНе стОит путать аналитику по счёту и аналитику по карточке ТМЦ !
Если мы будем совать ТМЦ-аналитику в Гл.Книгу то эту книгу просто разорвёт. :)
Разве бухгалтеру важно знать, какого цвета паркет мы отпустили такого-то числа ?


эккая лихая мысль. по большому счету, это все сильно зависит от
применяемой учетной политики. в нормальных организациях бухгалтеру
нужно видеть реальный код (аналитику ТМЦ) в проводках, просто
для корректного определения стоимости остатков и контроля в целом.
"усредневзешенные" схемы - это все от серости, бедности и т.д.
кроме того, есть такая штука, как ISO 9001. партионный учет и все такое ;)

а для сводного финансового учета - так для того придумали и обзоры
материализованные и пр. промежуточные сводные таблицы. в
конце концов - проводки на отчете сгруппировать - это не учет поставить ;))

FoxLamer автор... остаток имеет период
действия - с - по BEG_DATE (NOT NULL), END_DATE (NOT NULL) соотвественно.
индекс строить примерно так. ACCOUNT_NUM, END_DATE, BEG_DATE.
правда, тут есть небольшие проблемы с партицированием.


Не понял, зачем END_DATE, BEG_DATE?
Разве не достаточно в таблице остатков иметь одно поле saldo_date?

нет конечно.
у тебя с 1-е по 5-е число - сальдо по аналитическому ряду дебет сто,
с 6-го по 10-е - ноль, с 11-го - кредит двести.

и скажи мне мил человек, каким таким запросом ты получишь сальдо на

8-? SELECT * FROM xxx WHERE saldo_date -- ? чего ?

4321
при этом
1. проводка 1-на (сумма по дебету и кредету 1-на, и пишется в одной точке). Т.е. требование нормализации (и автоматической 2-й записи)

бред какой-то. какая-еще нормализация ?
сумму нужно отражать на полупроводке. сразу.
третья таблица не нужна и даже вредна.

иДПро - это нужно выбросить. равно как и сущность Проводки

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

вяжи полупроводки на документ основание и код операции
(ид по справочнику этих самих типовых операций)
первичный ключ (генеренный) на проводке - тоже не нужен.
никто на проводку (полу-) уже ссылаться не будет и не должен,
всесто суррогатного генерированного ключа вполне
приемлим составной уникальный ключ:

(ИдДокумента,ИдОперации,НомерСчетаАналитики,ДбКр,ДатаПроводки)

ДбКр - нужны только для случаев проводок вида 62-62.
Дата проводки - для сторнирующих (перерасчетных) проводок по документу
(и то, это - еще тот вопрос).


4321

2. Никакого юниона я не вижу. Можете считать суммы как по своим полупроводкам (простым джойном Счетов к проводкам разворачиваете их в свои
"полупроводки")


UNION возникает при двух полях счетов на запись -
Дебет-счет-аналитика, Кредит-счет-аналитика, Сумма

4321
3. Не утверждаю, что это хорошая структура, но
да нормально (ни хорошо, ни плохо).
как курсовой - даже на пять баллов потянет.