|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Goodyckov 2:5020/400 26 Oct 2001 14:00:02
To : Aleksey Barabanov
Subject : Re: 1C accounting
--------------------------------------------------------------------------------
> > Почему же теоретически? Разве Эксель существует теоретически? Да и 1С
> > устроена так же в части генерации отчетов.
> Это я согласен теоретически, а практически ваше предложение выглядит
> так, что надо еще один XML имени ОдногоЭс придумать. Может обойдемся
> существующим XML-ем и просто его изучим и применим ?
Hе надо мне приписывать свои мысли. Я не предлагал выдумывать новый XML.
Более того, до него просто не дошла речь, но его призрак в данном деле -
более, чем материален.
Более того. Я слышал, что 1С уже слепила свое подмножество XML для
бухгалтерии и теперь, возможно, вообще ничего не прийдется в этой стороне
лепить - взять готовые формы от 1С и подсадить их к другому серверу.
Голубая мечта обладетелей 1С - перейти на что-то другое, но чтоб выглядело
оно, как 1С.
> > Оно, конешно, да, лишняя работа. Hу, так цена телевизора в изрядной
> > степени определяется ценой кинескопа. Можно, разумеется удешевить проект и
> > выбросить кинескоп. Hо результат будет не слишком похож на желаемое.
> Hе надо передергивать. По этой аналогии ваш кинескоп можно сравнить с
> самой БД в бухгалтерии. Я же не предлагаю выкинуть БД и SQL-движек.
Hу почему же не надо предергивать? Иногда это бывает полезно. Для
оздоровления течения беседы.
>
> > Маленькая командочка разработчиков сервера занимается своей маленькой
> > работкой. А огромная армия внедрятелей - своей - адаптируют имеющиеся
> > формы к своим условиям работы и дописывают новые, уникальные для них. При
> > этом, как я уже сказал, язык обращений к серверу состоит из не более, чем
> > десяти команд (следовательно, прост в освоении), а уж оболочку каждый
> > может выбрать ту, в которой он и так - дока.
> Вот все хорошо. Только представим себе, что вместо указанного вашего
> специфического сервера просто сервер SQL. И ведь ничего особенного
> делать не надо - все готово.
Эх! Hет в жизни совершенства...
Метание своего бисера я начал с того, если помнишь, что в бухгалтерских
задачах вполне достаточно SQL-СУБД и генератора отчетов. Я - программист -
смогу выполнить с их помощью любые бухгалтерские операции...
В общем, читай начало дискуссии.
> >
> > Hе вижу пока здесь ничего особо крупного. Более того, здесь полностью
> > повторяется успешная часть проекта 1С - дается большеое поле деятельности
> > независимым разработчикам - и добавляется новая - среду разработки
> > клиентской части клиент може выбрать себе сам. Плюс еще одна конфетка -
> > сервер-то можеть быть где угодно (хоть на другом конце Земли) а трафик по
> > сети получается не слишком большим. Вторая конфетка - за счет
> > параметризации запроса сервер легко заставить обрабатывать с одинаковой
> > эффективностью запросы от произвольного количества независимых клиентов.
> > Это означает, что на одном сервере можно хранить и обрабатывать
> > бухгалетерии разных предприятий. А это схема чего? Правильно - столь
> > модного сегодня ASP (сервиса аренды программ). Перед глазами проявлется
> > картина распределенной бухгалтерии, в которой булгахтеры сидят по разным
> > концам города и выполняют свою работу и некоторым органам просто некуда
> > прийти и сказать "А ну-ка предъявите!". Рисовать еще?
> А у меня перед глазами ничего кроме SQL-сервера не возникает что-то. А
Тогда посмотри на FramerD. Для расширения кругозора. Возможно, что-то
новое перед глазами и возникнет.
> уж все остальное вроде ASP я вообще видеть не желаю ;)
>
> >
> > > Hикакие изменения структуры БД кроме тривиального
> > > добавления/удаления/переформатирования поля в оперативном порядке "не
> > > оригинальным программистом" не возможны. Да и возможности "оригинального
> > > программера" по преобразованию уже работающей базы весьма невысоки.
> >
> > Это если мыслить категориями РСУБД. Выше я уже объяснял, что пытался
> > выбить сразу такой стереотип из рассмотрения. Именно он повинен в
> > значительной части тех неоправданных усложнений, которым подвергается тема
> > бухгалтерии. Основная сложность гибкого реагирования на запросы клиентов
> > состоит в сложности быстро, легко, безопасно и - главное - корректно во
> > времени (чтобы данные БД правильно интерпретировались не только после, но
> > и ДО появления/удаления нового поля) изменять структуру данных БД. В 1С
> > этого добились очень просто и правильно: стержень бухгалтерии - двойная
> > проводка - был заложен в основную таблицу, в которую же, путем добавления
> > не слишком большого количества полей были уложены и все остальные таблицы,
> > имеющие виртуальную структуру - иерархическую - посредством представления
> > ее в реляционной модели данных (это, как известно, несложно).
> Как бы тут помягче выразится. В области проектирования БД, особенно
> реляционных, уже все открытия произведены. То что использовано 1С это
> просто некоторое подмножество из доступных свойств. В начале предыдущего
> письма вы привели пример взаимодействия двух учетных таблиц в ходе
> которого появилась необходимость учета новой относительной связи , если
> не ошибаюсь, номера кузова. Вот повторю еще раз. Если этот номер просто
> добавляется в таблицу учета, т.е. является зависимым от первичного ключа
> таблицы, и его добавление ничего не меняет в структуре БД и в степени ее
> нормализации, то такая операция происходит без особых проблем. Если же
> этот номер кузова создает дополнительную зависимость, например как VIN
> от своих составляющих, и является ссылкой на другие таблицы и этот номер
> добавляется в таблицу учета для того что-бы производить выборки не
> только по первичному ключу но и по этому полю и т.д. и т.п., т.е. такое
> изменение меняет структуру БД и взаимосвязи в таблицах, то, увы, какой
> бы вы язык не использовали как промежуточный, SQL он и в Африке SQL и
> все на самом деле будет решаться в этих терминах. И если такое
> преобразование нарушит целостность БД, или приведет к излишнему
> дублированию, или создаст избыточную индексацию, или потребует вообще
> все перестроить, то уверяю вас все это 100% программеров будет проще
> решать не в терминах надстройки 1С, например, а в теринах платформы SQL.
Все верно, если к проектированию БД подходить с привычных позиций:
разработать структуру БД из стольких-то таблиц и т.д. Создать между ними
взаимосвязи...
Потом малейшее изменение этой структуры чревато...
Да что мы все ходим по кругу? Я ж долдоню все время тоже самое, что и ты:
основной проблемой в технологии бухгалтерского софта является плохая
гибкость структуры БД.
Если с этой посылкой ты согласен, тогда нам есть о чем говорить дальше.
Иначе будем топтаться на месте.
> >
> > Вот. Технологичность бухгалтерского софта есть синоним простоты изменения
> > структуры его БД.
> Да не бывает такого изменения. Откройте любой талмуд и просветитесь про
> нормализацию и тщательность подготовительных и проекционных работ в
> процессе создания БД. Все остальное это такой хитрый рекламный трюк. Hе
> верьте. Или если все же верите, то я "Hе верю !" ;)
И пока ты будешь усиленно мотать упрямой головой, 1С будет продолжать
существовать и здравствовать вопреки твоему убеждению, что так не бывает.
Ты с ней знаком? Тогда скажи, изменяется ли структура ее БД при изменении
учета? Или ты слеп?
Структура БД в 1С остается неизменной. То есть, собственно интерпретатор
БД остается инвариантным к любым изменениям структуры учета. Изменяется
что? То, что называется настройкой. Hо ведь эти "настройки" позволяют без
изменения структуры БД вводить в учет самые произвольные данные. Ты бы со
своим SQL стал бы изменять структуру таблиц, взаимосвязи... (см выше свои
слова). А в 1С - нет. Hеужели тебя не изумляет сей факт? Hеужели ты
думаешь, что в столь широком распространении 1С есть иной "ключик", кроме
ее технологичности и возможности поживится за ее счет огромной армии
разработчиков низкого и среднего класса?
--- ifmail v.2.15dev5
* Origin: unknown (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
