Re: Предложения по хранению первичных документов



Posted by Анатолий Анимица on September 03, 1999 at 00:03:57:

In Reply to: Предложения по хранению первичных документов posted by Васеленко Сергей, Фирма КАРДИНАЛ on September 01, 1999 at 02:41:08:

Сергей Васеленко предлагает формат хранения и метод доступа к первичным документам, компенсирующий непригодность файловых систем Win95..98 (FAT16,FAT32) для работы с большими каталогами (десятки и сотни тысяч файлов; с NT, как было показано ранее А.Водяником и проверено мною, дела не так плохи, по крайней мере, на каталогах с 50000 файлов). В смелом и не лишенном оснований предположении, что сервер ФБП справится с этим делом получше штатных средств операционной системы. Идея неплоха и находится в ряду опытов аналогичного вида, только с компрессией этого TXA.TXA файла, с формированием всего массива документов в оперативной памяти в сеансе сервера динамически, но не мешало бы разобраться, а чего же мы хотим от этих первичных документов?

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

2. Как верно отмечает Сергей Васеленко - прочитать, при необходимости этот документ по адресу (коду) создавшей его операции.

И больше ничего!

Если придерживаться ортодоксального использования ФБП, где вся информация находится только в записях операций и в стартовых файлах acnt.a3p и *.b, при нынешнем формате операции затруднительно сохранить в них и только в них все атрибуты документа в распределенном в записях операций виде. В моих системах, например, части операторов разрешен прямой доступ к каталогу TXA для записи откорректированного редактором только что созданного файла первичного документа, но это не есть хорошо.




В "чистых" гипотетических системах набор документов легко создать динамически на старте каждого сеанса сервера, что мы и видим отчасти в версиях 3.0Х. Можно пойти по этому пути и дальше, но тогда мы сами установим себе предел, который помешает в ситуации, которуя я опишу ниже.

Что же по сути предлагает Сергей Васеленко? Он предлагает ни много ни мало создание собственной файловой системы внутри сервера ФБП. Посмотрите сами:

: Предложение:
: все документы хранятся в едином файле, например, TXA.TXT.

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

: При этом запоминается смещение в байтах начала и длина первичного документа.

: Т.е. для каждого кода операции дополнительно хранятся:
: - временной штамп первичного документа,
: - смещение начала документа,
: - длина первичного документа.

: Затем, при чтении файл открывается в режиме прямого доступа, и, начиная от начала документа, считывается определенное количество байт, которое и отсылается напрямую клиенту.

: При таком подходе возникает еще один интересный момент - все сформированные документы хранятся, т.е. если организовать определенным образом индекс, то можно будет иметь (и выбирать в дальнейшем) любые версии документов.

: В хранении документов есть один нюанс - нельзя перештамповывать операции.
: Иначе - документы одних операций попадают в другие.

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

: Этот режим перештамповки является к тому же бесплатным.


И так далее. В этом супе не хватает очень малого: добавить индексную таблицу (аналог таблицы размещения файлов), обеспечить уничтожение и переименование индексов при уничтожении и перименовании операций, и мы получим dblspace.exe не хуже, чем у Microsoft.

Если последовательно идти по пути закрытия доступа к этим файлам всеми способами, кроме запросов к серверу - над этим надо еще хорошенько подумать, что-то в этом есть. Уже не заглянешь в каталог TXA руками и глазами, не переместишь и не подправишь ничего сам, то есть администрирование упростится, а также требования к квалификации администратора снизятся. Но мне почему-то очень не хочется работать для обеспечения работоспособности все более и более ничего не понимающих людей в ключевых системах жизнеобеспечения предприятий, к каковым в полной мере нужно отнести бухгалтерские системы. Мне больше нравится их учить. В том числе и методам организации данных в ЭВМ.

Такая "файловая система" будет отвлекать сервер от его прямой задачи - построения временнОй трассы вектора состояний системы и реакции на запросы клиентов, то есть, на мой взгляд, порочна.

Тут в "Финансовой газете" по нам опять слегка прошлись - уважаемый мной и всеми нами Евгений Шуремов подбросил дров в костер аутодафе на тему, что "Финансы.." до сих пор пишут все "от операции", так что стороннники "Отдокументности" получили в его статье очередную мощную поддержку.

Теперь я излагаю то, о чем обещал выше. Ладно. От документа так от документа. Допустим, у нас есть некий набор форм *.rpt, которые можно исполнять на сервере в диалоге с клиента. Я молчу, насколько велико многообразие таких форм, чувствительных (у меня), к каждой веденной букве, строке или числу: то есть, у формы нет графического образа! Куда кривая вывезет, такой и будет эта форма! Ну ладно, это особенность "Финансов" - такая гибкость, надо помнить, а что эта форма выдаст на следующем шаге, если написать то-то и то-то и т.д., Оператор в полной мере эту форму программирует, и у меня он знает об этом. Никакие ниспадающие меню, JAVA апплеты и прочие хитрости все это многообразие отобразить не позволяют.

Ладно, от чего-то в угоду массовости можно и отказаться: скажем, ограничить возможность выбора этапом преамбулы, например, 3..5 вопросами диалога на старте формы, их даже можно отобразить в виде менюшек, можно пиктограммами или даже иероглифами все это нарисовать, все равно мы все скоро будем китайцами (шутка), и на диагонали даже в 20 дюймов особо не разгонишься писать много слов, это вам не папирус, а скорее вавилонская керамика (во, не иероглиф, а клинописный знак в меню!), а потом уже что-то вроде многострочного ввода с подбитием итогов. Легко. Если JAVA скриптов навстраиваить в KUKU*.RPT, и не такое можно изобразить. Именно это я и имел в виду в заметке
"Сильная скриптография в ФБП"
, написанной еще в этом феврале.

Но тогда давайте пойдем чуть дальше. Давайте сделаем еще две функции в формах:

1. Давайте встроим в язык запросов к серверу запрос вида "я, клиент, тут файл импортировал - например, сканировал, или взял из внешней базы, или еще как-то. Так что будь добр:

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

б) запиши ссылку, что этот файл лежит на www.geocities.com/readcobra/~118, обещали, что не будут удалять

в) запиши ссылку, что этот файл ququinput1.pdf будет лежать в //user18/c:/pdfs/ или как там еще у Novell Directory Service это пишут для больших гетерогенных каталогов.

Вот тогда красота будет!

Взял лопату, загрузил пачку счет-фактур в сканер, написал, где лежат, расшифровал, склепал документ, от которого я эту историю и начал, отдал серверу, он наваял операций, проштамповал их, забрал сам документ, отданный ему через каталог обмена, запихнул его TXA, а туда еще и ссылки на сканкопии документов вставил (хотя это может и клиент сделать, собрав всю пачку в один конверт). И тогда при чтении, например, моей личной карточки, хранимой как первичный документ, можно будет увидеть улыбающуюся морду моего лица или краткий видеофильм о том, как я принес накладную в бухгалтерию, которая под этим штампом и хранится в базе данных ФБП.

Это отчасти фантастика, а отчасти можно сделать прямо сейчас - не хватает соглашений о кодировании. Или соглашений о запрете на произвольное вмешательство на запись в extrd.dat, тогда в нем можно это хранить.

Вернемся к идее Сергея. Мне она не нравится. Больно сложно будет все это сделать красиво. Может быть, не в этой жизни? На самом деле даже 1000 операторов при ежедневной работе и создании по 10 документов в день за год создадут всего-навсего два с половиной миллиона документов, если их в выходные не пускать на работу, конечно. Это немного, и можно не мучиться с временми доступа, вон, Alta Vista работает и ничего, а у нее побольше будет таких ссылок и каталогов. Способ каталогизации документов не принципиален, только пути бы надо прописать - ну зачем жестко из \TXA\A-JAN хватать документ, если он может быть где угодно. То есть я свою старую идею: каталогизировать в структуре \TXA\19990904\IVVV-785.TXA снимаю. Хотя в ней что-то есть, скажем, для доступа к этим базам сервер-агентов, например, агентов резервного копирования каталогов и их репликации. Посмотел на файл-описатель каталога, сравнил с таким же в репликате и ушел. И не лопатил 10000 файлов трехмесячной давности, потому что никто их не трогал. А где надо - реплицировал, отметил, и спи отдыхай.


Ну я и написал! Уж не обессудьте. Як кажуть на Украiiнi, звиняйте, куме.

Ваш ААА






Пpишедшие ответы: