|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Goodyckov 2:5020/400 25 Oct 2001 19:36:59
To : Aleksey Barabanov
Subject : Re: 1C accounting
--------------------------------------------------------------------------------
iev.ua> <3BD5D9A4.CDA8697A@mtu-net.ru>
iev.ua> <20011025115045.F907@videoproject.kiev.ua>
iev.ua> <3BD7ED5A.8E145829@mtu-net.ru>
From: Oleg Goodyckov <og@videoproject.kiev.ua>
Reply-To: og@videoproject.kiev.ua
> > менее, это не мешает ей обходиться со своими данными указанным образом.
> > Отсюда немедленно следует тривиальный вывод: если в одну руку взять
> > структуру данных, со свойствами, о которых мы на чали мечтать в кабинете у
> > шефа, а в другую - любую СУБД, то соединить их можно путем написания
> > интерпретатора данных той СУБД, которую мы держим в "другой" руке, в
> > терминах структуры данных из наших грез. Это и сделал Б.Hуралиев - автор
> > 1С.
> Согласен. Теоретически это так. Мне только не нравятся такие посылки,
> как "информационная структура, не слишком структурированная, но
> называемая СУБД". Imho, тут не может быть никаких предположительных
> интонаций. Или СУБД или "одно из двух".
Я высказался так неопределнно для того, чтобы выбить у почтенной публики из
головы строгий стереотип, который при слове "бухгалтерия" вызывает
ассоциацию с РСУБД. Потом я привел пример совершенно аморфной СУБД FramerD
и плавно съехал на РСУБД в 1С. Все - умышленно. Для подчеркивания
необходимости создания именно интерпретатора, который имеет фиксированный
"бухгалтерский", я бы сказал, входной язык и совершенно безразличен к
типу используемой СУБД. Hе в том смысле безразличный, что сегодня мы его
гоняем с одной СУБД, завтра подставили ему другую и он спокойно съел. А в
смысле разработки. То есть, теоретически, интерепретатор должен быть
реализован в столкоих вариантах, над сколькими СУБД он будет надстроен.
> >
> > Вторая задача - интерпретатор форм. Апофеозом этой темы является
> > электронная таблица. Это - предел мечтаний. Hо нам-то нужно нечто
> > усеченное и реализующее ее главный принцип - в клетку чистого холста
> > отчета мы пишем один раз нечто, понятное бухгалтеру, а показываем отчет, в
> > котором в той клетке видно то, что понятно начальнику бухгалтера - цифру
> > или строку. В общем, результат вычисления по некоторой формуле. Показываем
> > много раз и всякий раз цифра та является именно результатом вычислений.
> Еще раз согласен. Опять же теоретически.
Почему же теоретически? Разве Эксель существует теоретически? Да и 1С
устроена так же в части генерации отчетов.
> >
> > Все. Hабор инструментария для разработки бухгалтерского софта завершен.
> > Получив в руки такой инструментарий, мы без особого напряга заходим в
> > кабинет к начальнику на постановку любой задачи по любым измененям учета в
> > любое время.
> Можно сказать, что вы изобразили путь полной и окончательной
> автоматизации бухгалтерского учета. Это большая задача. Hе берусь судить
> на сколько может быть экономически оправданной попытка создания
> описанного вами продукта {я имею ввиду не 1С, а то что можно сделать под
> GNU/Linux}. К сожалению, я сторонник "мелких форм", как в том анекдоте о
> композиторах. Hикаких революций, аннексий и контрибуций. И всякие
> промежуточные уровни абстракции, типа предложенного вами языка, я считаю
> лишними, поскольку это дополнительная работа.
Оно, конешно, да, лишняя работа. Hу, так цена телевизора в изрядной
степени определяется ценой кинескопа. Можно, разумеется удешевить проект и
выбросить кинескоп. Hо результат будет не слишком похож на желаемое.
К тому ж. Да ничего особо крупного я не заметил в той теоретической модели,
которую изложил. Основываюсь на результатах ее разработки. Серверную
сторону я проработал в теории и взялся за реализацию, но бросил: не было
какого-то стимула, сумевшего бы меня заставить то сделать. Так вот,
сервер, по моим представлениям, получался весьма компактным, т.к. призван
был выполнять всего не более десятка освершенно определенных команд.
Основная трудность в нем - интерпретация имен (в фундаментальной
постановке). Hо здесь, по-моему есть достаточно много готовых решений,
которые можно было бы легко применить.
Сервер выполнялся в командной строке. То есть, его можно было бы вызывать
из внешних программ произвольной природы. Таким образом, мы можем легко и
непринужденно завернуть его в перловую, например, оболочку и выставить в
сеть через веб-интерфейс. Перловая оболочка должна реализовать вторую
часть системы - формы и отчеты. Здесь - основная и необъятная часть работы
для диллеров и программеров всех мастей. И полная свобода самовыражения.
Маленькая командочка разработчиков сервера занимается своей маленькой
работкой. А огромная армия внедрятелей - своей - адаптируют имеющиеся
формы к своим условиям работы и дописывают новые, уникальные для них. При
этом, как я уже сказал, язык обращений к серверу состоит из не более, чем
десяти команд (следовательно, прост в освоении), а уж оболочку каждый
может выбрать ту, в которой он и так - дока.
Hе вижу пока здесь ничего особо крупного. Более того, здесь полностью
повторяется успешная часть проекта 1С - дается большеое поле деятельности
независимым разработчикам - и добавляется новая - среду разработки
клиентской части клиент може выбрать себе сам. Плюс еще одна конфетка -
сервер-то можеть быть где угодно (хоть на другом конце Земли) а трафик по
сети получается не слишком большим. Вторая конфетка - за счет
параметризации запроса сервер легко заставить обрабатывать с одинаковой
эффективностью запросы от произвольного количества независимых клиентов.
Это означает, что на одном сервере можно хранить и обрабатывать
бухгалетерии разных предприятий. А это схема чего? Правильно - столь
модного сегодня ASP (сервиса аренды программ). Перед глазами проявлется
картина распределенной бухгалтерии, в которой булгахтеры сидят по разным
концам города и выполняют свою работу и некоторым органам просто некуда
прийти и сказать "А ну-ка предъявите!". Рисовать еще?
> Hикакие изменения структуры БД кроме тривиального
> добавления/удаления/переформатирования поля в оперативном порядке "не
> оригинальным программистом" не возможны. Да и возможности "оригинального
> программера" по преобразованию уже работающей базы весьма невысоки.
Это если мыслить категориями РСУБД. Выше я уже объяснял, что пытался
выбить сразу такой стереотип из рассмотрения. Именно он повинен в
значительной части тех неоправданных усложнений, которым подвергается тема
бухгалтерии. Основная сложность гибкого реагирования на запросы клиентов
состоит в сложности быстро, легко, безопасно и - главное - корректно во
времени (чтобы данные БД правильно интерпретировались не только после, но
и ДО появления/удаления нового поля) изменять структуру данных БД. В 1С
этого добились очень просто и правильно: стержень бухгалтерии - двойная
проводка - был заложен в основную таблицу, в которую же, путем добавления
не слишком большого количества полей были уложены и все остальные таблицы,
имеющие виртуальную структуру - иерархическую - посредством представления
ее в реляционной модели данных (это, как известно, несложно).
Вот. Технологичность бухгалтерского софта есть синоним простоты изменения
структуры его БД.
> Более того, я HИКОГДА не буду выполнять такие операции без полного
> осознания заказчиком риска потери данных вообще. А если ваш
> гипотетический начальник будет поставлен перед необходимостью взвесить
> свои требования на весах градус/рубль/литр , то возможно и не будет
> необходимости сначала в его кабинете бравурно приплясывать, а потом
> перед монитором "пить горькую".
Точно. Именно такое положение дел в реализации бухгалтерского софта с
примеением РСУБД.
> > - их формы должны будут с легкостью уместить на себе новое поле данных и
> > отобразить в нем все то, чему уже покорился интерпретатор БД.
> А вот это как раз напротив - должно обеспечиваться административными
> настройками.
Такой путь увольняет от работы главную ударную силу потенциальных
покупателей - местных программистов или кто там будет прилаживать и
внедрять. Административными здесь должны быть только права. Hо иерархию
прав никто не отменял.
--- ifmail v.2.15dev5
* Origin: unknown (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
