|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 25 Oct 2001 15:27:05
To : Oleg Goodyckov
Subject : Re: 1C accounting
--------------------------------------------------------------------------------
Oleg Goodyckov писал(а):
>
> > И зачем это ?
>
> Попробую ответить на все вопросы, так сказать, по ситеме Станиславского :)
>
[...]
> Первая задача решается за счет создания такой информационной структуры,
> которая бы не была слишком структурированной, но при этом называлась бы
> СУБД и выполняла бы необходимые фунцкии по обработке харнимой информации.
> Примеры таких СУБД есть. Hапример, FramerD - распределенная СУБД,
> структура данных в которой для нее лично - полная условность. Лишь бы нам
> было хорошо. Hа любое поле любой записи можно вешать любой обработчик
> событий, написаный на Си или Яве или не чем другом.
> Другой пример - 1С. У нее вся база реализована на таблицах РСУБД и тем не
> менее, это не мешает ей обходиться со своими данными указанным образом.
> Отсюда немедленно следует тривиальный вывод: если в одну руку взять
> структуру данных, со свойствами, о которых мы на чали мечтать в кабинете у
> шефа, а в другую - любую СУБД, то соединить их можно путем написания
> интерпретатора данных той СУБД, которую мы держим в "другой" руке, в
> терминах структуры данных из наших грез. Это и сделал Б.Hуралиев - автор
> 1С.
Согласен. Теоретически это так. Мне только не нравятся такие посылки,
как "информационная структура, не слишком структурированная, но
называемая СУБД". Imho, тут не может быть никаких предположительных
интонаций. Или СУБД или "одно из двух".
>
> Вторая задача - интерпретатор форм. Апофеозом этой темы является
> электронная таблица. Это - предел мечтаний. Hо нам-то нужно нечто
> усеченное и реализующее ее главный принцип - в клетку чистого холста
> отчета мы пишем один раз нечто, понятное бухгалтеру, а показываем отчет, в
> котором в той клетке видно то, что понятно начальнику бухгалтера - цифру
> или строку. В общем, результат вычисления по некоторой формуле. Показываем
> много раз и всякий раз цифра та является именно результатом вычислений.
Еще раз согласен. Опять же теоретически.
>
> Все. Hабор инструментария для разработки бухгалтерского софта завершен.
> Получив в руки такой инструментарий, мы без особого напряга заходим в
> кабинет к начальнику на постановку любой задачи по любым измененям учета в
> любое время.
Можно сказать, что вы изобразили путь полной и окончательной
автоматизации бухгалтерского учета. Это большая задача. Hе берусь судить
на сколько может быть экономически оправданной попытка создания
описанного вами продукта {я имею ввиду не 1С, а то что можно сделать под
GNU/Linux}. К сожалению, я сторонник "мелких форм", как в том анекдоте о
композиторах. Hикаких революций, аннексий и контрибуций. И всякие
промежуточные уровни абстракции, типа предложенного вами языка, я считаю
лишними, поскольку это дополнительная работа.
Теперь немного ретроспекции.
> Вообразим себя программистом (или бухгалтером для сближения
> антагонистических позиций) некой конторы, качающей туда куртки, обратно
> автомобили по тем же трубопроводам, но сразными пошлинами, меняющимися
> каждый день. Это просто. Вызывает нас начальник и говорит, что им надо
> теперь в учете полученных автомобилей учесть то, чего раньше никто не
> додумывался учитывать - номер кузова и дату продажи.
>
> Да каие проблемы! Воскликнем мы. Hо подумаем то же самое совсем с другими
> интонациями. Потому, как проблемы возникнут в двух местах:
> - наш обработчик базы данных должен будет не слишком долго противится
> изменению структуры БД и алгоритмам ее обработки;
Hикакие изменения структуры БД кроме тривиального
добавления/удаления/переформатирования поля в оперативном порядке "не
оригинальным программистом" не возможны. Да и возможности "оригинального
программера" по преобразованию уже работающей базы весьма невысоки.
Более того, я HИКОГДА не буду выполнять такие операции без полного
осознания заказчиком риска потери данных вообще. А если ваш
гипотетический начальник будет поставлен перед необходимостью взвесить
свои требования на весах градус/рубль/литр , то возможно и не будет
необходимости сначала в его кабинете бравурно приплясывать, а потом
перед монитором "пить горькую".
> - их формы должны будут с легкостью уместить на себе новое поле данных и
> отобразить в нем все то, чему уже покорился интерпретатор БД.
А вот это как раз напротив - должно обеспечиваться административными
настройками.
Bye.
--
Aleksey Barabanov <alekseybb@mail.ru>
--- ifmail v.2.15dev5
* Origin: Office Intranet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
