Общие вопросы структуры ИБ. Прошу поделится опытом.

[yeger]

Заранее предупреждаю, что изложение будет несколько сумбурно.
При общем понимании работы финансовой базы данных задумался о "философском" вопросе. Есть различные регистры, предназначенные для отображения одного и того же документа (транзакции, записи, как хотите назовите). Регистр нужен для получения отчетности, больше в общем-то и не зачем его держать. Если рассмотреть регистр как объект, положим в 1С, то видно следующее - документ при проведении записывает данные в регистр, дублирует по сути, то что уже в нем (документе) находится в виде нужном регистру. Есть у регистра ссылка на какой-либо документ, точка времени этого документа, есть набор измерений (ссылок на значения др. таблиц) и ресурсов (числа). Когда размышлял об организации регистра для своей программы, подумалось - а нужно ли? Не проще ли написать вьюху, в которую при необходимости включать новые виды документов.
И одолели меня сомнения. Ведь уже подготовленную таблицу прочитать будет быстрее. Опять же, вьюха позволит не заботится о таких мелочах, как, например, последовательность документов, сама тут же пересчитается. Что же будет быстрее, как сделать правильнее?

Прошу поделится опытом, как вы организовывали регистры в ваших программах, таблицами, представлениями или вовсе как-то, как я пока еще не вижу себе?

P.S.: Вопросы, а зачем регистры вообще и нравоучения, что все можно сделать без них, прошу не писать.

[Little_Roo]

Есть различные регистры, предназначенные для отображения одного и того же документа (транзакции, записи, как хотите назовите)

Действительно ОЧЕНЬ сумбурно Регистры чего - букв? А транзакция и запись - вообще разного поля ягоды

точка времени этого документа

Это что за зверь ???

[yeger]

Возьмем самый простой пример, есть 3 документа: Приход товара на склад, продажа товара со склада, оплата товара.
В любой момент времени нас интересует состояние остатка на складе и состояние долгов. Регистра следовательно 2: "складские остатки" и "взаиморасчеты".
Для регистра "складские остатки" нас будет интересовать в любой момент времени сколько единиц и на какую сумму есть по определенному товару на определенном складе. Точка времени нужна для того чтобы быстро рассчитать сколько остатка было, положим, 4 минуты 40 секунд назад. На практике, ну хоть неликвид или уходимость за период прикинуть.
Для регистра "взаиморасчеты" нас будет интересовать в любой момент времени сколько мы или нам должны денег по определенному контрагенту в определенной валюте (с которой, мы с контрагентом расплачиваемся или общей для системы). А точка времени нужна, ну допустим, построить график дебиторской задолжности за период.
Точка времени - поле "DateTime".

Документы будут отражены
"приход товара на склад": + "складские остатки", - "взаиморасчеты"
"продажа товара со склада": - "складские остатки", + "взаиморасчеты"
"оплата товара": - "взаиморасчеты"

Транзакция как термин конечно же совсем не идентична записи, все понимаю. Но вот положим в 1С - документ, а в сапе - транзакция, а в общем смысле - запись о хозяйственной операции.

[Little_Roo]

Транзакция как термин конечно же совсем не идентична записи, все понимаю

Ну да, то есть совсем не

Но вот положим в 1С - документ, а в сапе - транзакция, а в общем смысле - запись о хозяйственной операции.

Отделяем мух от котлет - 1С и Lazarus ??? сап (это вроде как болезнь рогатого скота) - запись ??? transact, field, record - выразитесь яснее - для какой базы данных, какие компоненты используете, версии FPC и Lazarus...
Иначе получается диалог глухого с немым, "...а телепаты в отпуске" (с)

Добавлено спустя 2 минуты 31 секунду:

Документы будут отражены
"приход товара на склад": + "складские остатки", - "взаиморасчеты"
"продажа товара со склада": - "складские остатки", + "взаиморасчеты"
"оплата товара": - "взаиморасчеты"

LazReport

[alexey38]

Прошу поделится опытом, как вы организовывали регистры в ваших программах, таблицами, представлениями или вовсе как-то, как я пока еще не вижу себе?

Регистры 1С (для незнающих 1С не нужно путать с регистрами процессора) определены ее идеологией. Их назначение хранить приращения и остатки на некий текущий момент, например, остатки товара уже есть в посчитанном виде в регистре. Если иметь только документы, то нужно делать выборку, брать сумму всех приходов и всех расходов, вычитая итоги получаем остаток. На файловой структуре 1С (лет 15 назад, объем БД намного превышал объем ОЗУ) это было единственным способом обеспечить приемлемое быстродействие в текущей деятельности. Также пересчет сумм только по регистрам была быстрее, т.к. файл с регистром был короче, чем файл с документом.

Как лучше делать. Если у Вас в целом мало документов, например, 20 документов в день, 5000 документов в год, то никакие регистры не нужны. Нужна таблица типа журнал документов, где в полях стоят нужные показатели типа суммы и т.п. Аналогичная таблица проводок по товару и т.п. Далее просте запросы дают нужные итоговые цифры быстро, и не надо ни каких последовательностей документов.

Если у Вас 5000 документов в день, а каждый документ содержит 100 позиций, то за год Вы получите 18 млн. движений товара, а если фирма работает 100 лет, то уже 2 миллиарда записей. Запросы будут работать медленее (особенно если есть 100 пользователей), тогда нужен либо особо мощный сервак, либо вводить промежуточные итоги.
Поэтому если вместо регистров сделать некую таблицу промежуточных итогов, например, понедельные итоги, то далье алгоритм, как в первом случае (где 500 документов в год), и нарушение последовательности - это пересчет только внутри одной недели.

[yeger]

alexey38
Спасибо, действительно очень хороший совет. Думаю от 15 тысяч в день (естественно, не боевая ИБ, кто мне такой проект даст), для любопытства отражать, посмотреть каково.
Промежуточные итоги это очень здраво, понятие закрытого периода, опять же никто не отменял. Мне даже стыдно, что сам не подумал.

Little_Roo
Ну... чувствуется, что фин. базами данных Вы либо не интересуетесь, либо просто троллите.

[Little_Roo]

Ну... чувствуется, что фин. базами данных Вы либо не интересуетесь, либо просто троллите.

Действительно, фин.базами НЕ интересуюсь... А про троллинг - Топик - он как, по теме форума ?
Бюстгалтерия, как якобы наука, эдесь???

[stikriz]

Отделяем мух от котлет - 1С и Lazarus ???

Кто мешает написать 1С на лазарус?
Про регистры. Вы же смотрели - там может быть несколько регистров на один документ? Как бы надо задуматься почему... Так вот, регистр - это как бы предварительный результат. Да, можно сделать вьюхи. Но. Бывает же регистр взаиморасчетов, например. Там сумма прихода или расхода по всему документу, а не по каждой строке. Почему-то мне кажется, что запрос тогда будет работать быстрее? Потом, если так уж не хочется делать как в 1С, а многие "крутые" пацаны и хрен смогут , то уже давно я знаю, что нормальные архитекторы БД, типо меня ( ) могут писать в регистры и из триггеров, однако. Регистры - полезная вещь, хоть как её назови. И, понятно, что их придумал не Нуралиев.

Добавлено спустя 7 минут 20 секунд:

Как лучше делать. Если у Вас в целом мало документов, например, 20 документов в день, 5000 документов в год,

То Вам надо, например, ежегодно делать пустую базу и переносить туда остатки...

[Brainenjii]

OLAP?

[yeger]

stikriz
"писать в регистры и из триггеров" откуда писать не суть важно, лишь бы на сервере, но все таки писать. При значимом для регистра изменении структуры, скорее всего "перепроводить" (опять термин 1С, прошу извинить), а не менять алгоритм выборки представления. Опять же, почитал про представления и не выяснил для себя кешируются или при перезапуске сервера пересчитываются целиком.
"Там сумма прихода или расхода по всему документу, а не по каждой строке. Почему-то мне кажется, что запрос тогда будет работать быстрее?" говорите абсолютно верно, тоже об этом думал, в пользу представлений играет тот момент, что не надо восстанавливать последовательность документов при изменении задним числом.
Brainenjii
Олап это хорошо. При хорошей, продуманной структуре регистров и вовсе великолепно.
Если есть возможность сделать куб на MySql, то роль регистров и вовсе будут выполнять соответствующие кубы.
А вот компонентов для лазаруса под него не видел. Дадите ссылку?

[Tango]

Что за спор, ну конечно же регистры, пусть запись в них медленная, но чтение мгновенное. Можно пересчитывать регистр в конце дня, а на текущий момент получать актуальные данные по регистру за предыдущий день+(Запрос/Вью) в текущем дне. У меня баланс пересчитывается раз в час, по загрузки документов. Правда у меня только один регистр, оборотов клиентов. И в базе ~3000 в день (скажем документов по одной позиции). И операторы смотрят в прошлое максимум на час, остатки они получают только из регистра.

[vada]

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

VIEW называется в терминах SQL СУБД.