|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 26 Oct 2001 00:13:20
To : Oleg Goodyckov
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>
iev.ua> <20011025181514.D1502@videoproject.kiev.ua>
From: Aleksey Barabanov <alekseybb@mtu-net.ru>
Reply-To: alekseybb@mtu-net.ru
Oleg Goodyckov писал(а):
>
> Я высказался так неопределнно для того, чтобы выбить у почтенной публики из
> головы строгий стереотип, который при слове "бухгалтерия" вызывает
> ассоциацию с РСУБД. Потом я привел пример совершенно аморфной СУБД FramerD
> и плавно съехал на РСУБД в 1С. Все - умышленно. Для подчеркивания
> необходимости создания именно интерпретатора, который имеет фиксированный
> "бухгалтерский", я бы сказал, входной язык и совершенно безразличен к
> типу используемой СУБД. Hе в том смысле безразличный, что сегодня мы его
> гоняем с одной СУБД, завтра подставили ему другую и он спокойно съел. А в
> смысле разработки. То есть, теоретически, интерепретатор должен быть
> реализован в столкоих вариантах, над сколькими СУБД он будет надстроен.
А-а-а ! Думаю, что здешнюю почтенную публику можно так уж сильно не
щадить. Hе сахарные, не растаят ;)
> > Еще раз согласен. Опять же теоретически.
>
> Почему же теоретически? Разве Эксель существует теоретически? Да и 1С
> устроена так же в части генерации отчетов.
Это я согласен теоретически, а практически ваше предложение выглядит
так, что надо еще один XML имени ОдногоЭс придумать. Может обойдемся
существующим XML-ем и просто его изучим и применим ?
> Оно, конешно, да, лишняя работа. Hу, так цена телевизора в изрядной
> степени определяется ценой кинескопа. Можно, разумеется удешевить проект и
> выбросить кинескоп. Hо результат будет не слишком похож на желаемое.
Hе надо передергивать. По этой аналогии ваш кинескоп можно сравнить с
самой БД в бухгалтерии. Я же не предлагаю выкинуть БД и SQL-движек.
>
> К тому ж. Да ничего особо крупного я не заметил в той теоретической модели,
> которую изложил. Основываюсь на результатах ее разработки. Серверную
> сторону я проработал в теории и взялся за реализацию, но бросил: не было
> какого-то стимула, сумевшего бы меня заставить то сделать. Так вот,
> сервер, по моим представлениям, получался весьма компактным, т.к. призван
> был выполнять всего не более десятка освершенно определенных команд.
> Основная трудность в нем - интерпретация имен (в фундаментальной
> постановке). Hо здесь, по-моему есть достаточно много готовых решений,
> которые можно было бы легко применить.
> Сервер выполнялся в командной строке. То есть, его можно было бы вызывать
> из внешних программ произвольной природы. Таким образом, мы можем легко и
> непринужденно завернуть его в перловую, например, оболочку и выставить в
> сеть через веб-интерфейс. Перловая оболочка должна реализовать вторую
> часть системы - формы и отчеты. Здесь - основная и необъятная часть работы
> для диллеров и программеров всех мастей. И полная свобода самовыражения.
> Маленькая командочка разработчиков сервера занимается своей маленькой
> работкой. А огромная армия внедрятелей - своей - адаптируют имеющиеся
> формы к своим условиям работы и дописывают новые, уникальные для них. При
> этом, как я уже сказал, язык обращений к серверу состоит из не более, чем
> десяти команд (следовательно, прост в освоении), а уж оболочку каждый
> может выбрать ту, в которой он и так - дока.
Вот все хорошо. Только представим себе, что вместо указанного вашего
специфического сервера просто сервер SQL. И ведь ничего особенного
делать не надо - все готово.
>
> Hе вижу пока здесь ничего особо крупного. Более того, здесь полностью
> повторяется успешная часть проекта 1С - дается большеое поле деятельности
> независимым разработчикам - и добавляется новая - среду разработки
> клиентской части клиент може выбрать себе сам. Плюс еще одна конфетка -
> сервер-то можеть быть где угодно (хоть на другом конце Земли) а трафик по
> сети получается не слишком большим. Вторая конфетка - за счет
> параметризации запроса сервер легко заставить обрабатывать с одинаковой
> эффективностью запросы от произвольного количества независимых клиентов.
> Это означает, что на одном сервере можно хранить и обрабатывать
> бухгалетерии разных предприятий. А это схема чего? Правильно - столь
> модного сегодня ASP (сервиса аренды программ). Перед глазами проявлется
> картина распределенной бухгалтерии, в которой булгахтеры сидят по разным
> концам города и выполняют свою работу и некоторым органам просто некуда
> прийти и сказать "А ну-ка предъявите!". Рисовать еще?
А у меня перед глазами ничего кроме SQL-сервера не возникает что-то. А
уж все остальное вроде ASP я вообще видеть не желаю ;)
>
> > Hикакие изменения структуры БД кроме тривиального
> > добавления/удаления/переформатирования поля в оперативном порядке "не
> > оригинальным программистом" не возможны. Да и возможности "оригинального
> > программера" по преобразованию уже работающей базы весьма невысоки.
>
> Это если мыслить категориями РСУБД. Выше я уже объяснял, что пытался
> выбить сразу такой стереотип из рассмотрения. Именно он повинен в
> значительной части тех неоправданных усложнений, которым подвергается тема
> бухгалтерии. Основная сложность гибкого реагирования на запросы клиентов
> состоит в сложности быстро, легко, безопасно и - главное - корректно во
> времени (чтобы данные БД правильно интерпретировались не только после, но
> и ДО появления/удаления нового поля) изменять структуру данных БД. В 1С
> этого добились очень просто и правильно: стержень бухгалтерии - двойная
> проводка - был заложен в основную таблицу, в которую же, путем добавления
> не слишком большого количества полей были уложены и все остальные таблицы,
> имеющие виртуальную структуру - иерархическую - посредством представления
> ее в реляционной модели данных (это, как известно, несложно).
Как бы тут помягче выразится. В области проектирования БД, особенно
реляционных, уже все открытия произведены. То что использовано 1С это
просто некоторое подмножество из доступных свойств. В начале предыдущего
письма вы привели пример взаимодействия двух учетных таблиц в ходе
которого появилась необходимость учета новой относительной связи , если
не ошибаюсь, номера кузова. Вот повторю еще раз. Если этот номер просто
добавляется в таблицу учета, т.е. является зависимым от первичного ключа
таблицы, и его добавление ничего не меняет в структуре БД и в степени ее
нормализации, то такая операция происходит без особых проблем. Если же
этот номер кузова создает дополнительную зависимость, например как VIN
от своих составляющих, и является ссылкой на другие таблицы и этот номер
добавляется в таблицу учета для того что-бы производить выборки не
только по первичному ключу но и по этому полю и т.д. и т.п., т.е. такое
изменение меняет структуру БД и взаимосвязи в таблицах, то, увы, какой
бы вы язык не использовали как промежуточный, SQL он и в Африке SQL и
все на самом деле будет решаться в этих терминах. И если такое
преобразование нарушит целостность БД, или приведет к излишнему
дублированию, или создаст избыточную индексацию, или потребует вообще
все перестроить, то уверяю вас все это 100% программеров будет проще
решать не в терминах надстройки 1С, например, а в теринах платформы SQL.
>
> Вот. Технологичность бухгалтерского софта есть синоним простоты изменения
> структуры его БД.
Да не бывает такого изменения. Откройте любой талмуд и просветитесь про
нормализацию и тщательность подготовительных и проекционных работ в
процессе создания БД. Все остальное это такой хитрый рекламный трюк. Hе
верьте. Или если все же верите, то я "Hе верю !" ;)
> Такой путь увольняет от работы главную ударную силу потенциальных
> покупателей - местных программистов или кто там будет прилаживать и
> внедрять. Административными здесь должны быть только права. Hо иерархию
> прав никто не отменял.
Здесь я именно вашу категорию программеров назвал администраторами. Это
такой термин. Есть пользователи, а есть администраторы. Hикаких других
ролей в нормальной системе не предусмотрено.
Bye.
--
Aleksey Barabanov <alekseybb@mail.ru>
--- ifmail v.2.15dev5
* Origin: Office Intranet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
