 |
Золотая середина... или очередной "велосипед"?
Привет всем!
В форуме весьма активно обсуждается вопрос "народной КИС", поэтому - если кому интересно, можно посмотреть на еще один вариант видения решения (возможно - изобретен очередной "велосипед") по ссылке:
http://www.rsfin.dn.ua/new_project.htm
Проект разрабатывается, но, как обычно бывает, времени ему уделяется мало, в связи текучкой...
Если будут мнения, то было интересно их прочитать.
С уважением, Виктор.
mailto: rsfin@rsfin.dn.ua
Виктор, на сайте не слова про технологии. Но насколько я понял у вас система написана на Фокс Про? А как же соответствие техническому заданию? "Система должна быть реализована как клиент-серверное приложение"
Кстати ссылка на сайт без описания - это типичная реклама. Вы писали, что времени у вас много - так напишите статью про свою систему. Мы её с удовольствием почитаем.
Всех благ!!!
Чувелёв Андрей
ps: Всё вышеизложенное является моим частным мнением и не может претендовать на полноту изложения.
Добрый день, Андрей!
Совершенно верно - Visual FoxPro. Сначала надо ее разработать в клиент-серверной технологии команд и процедур, а уж потом думать к какому SQL прикрутить... И Вы знаете, что Visual FoxPro это позволяет.Сообщение от Dracosha Andrew
Извиняюсь, совершенно не преследовал цель - рекламу. Просто в форуме невозможно разместить текст с картинкой, поэтому создал страничку на своем сайте, без "опознавательных знаков". Или я снова неправ или чего-то недосмотрел? Совершенно не буду возражать, если Вы переместите текст и картинку на Ваш ресурс, без ссылки на мой сайт.
Я с удовольствием напишу статью о системе, когда она будет готова. В настоящее время я хотел лишь представить, как вариант, структурную схему, возможность совмещения бухгалтерского и управленческого учета и наращивания функциональности системы. Может где-то я и ошибаюсь - "глаз замылен"... поэтому интересно было-бы почитать мнения и критику.
С уважением, Виктор.
P.S. А вот со свободным временем - не получилось...
Знаю. Только то что Вы собираетесь прикручивать это remote view, или связанные таблицы. Это вы весю прелесть SQL погубите.Сначала надо ее разработать в клиент-серверной технологии команд и процедур, а уж потом думать к какому SQL прикрутить... И Вы знаете, что Visual FoxPro это позволяет.Ничего там нет. В смысле оригинального там нет ничего. Дело в том, что даже пресловутая 1С построена от документа. Документ фиксирует событие и рождает ряд аналитик-проводок. Как? Это зависит от настроек. Извините. Давайте, что-нибудь поподробнее. Например. Структуру данных .как вариант, структурную схему
Всех благ!!!
Чувелёв Андрей
ps: Всё вышеизложенное является моим частным мнением и не может претендовать на полноту изложения.
Почему Вы так решили? Разве я о таком решении писал? Не надо меня обвинять в том, чего я и не думал делать! ;-)
Угу. Только, извините - СИНТЕТИЧЕСКИХ проводок... Это во первых. Во вторых - все почти так, только "трошечки" не так... В 1С нет такого метода, как "глубокая" транзакция (включая вложенные), начинающаяся созданием события и завершающаяся моментом сохранения первичного объекта учета (документа), с фиксацией результатов первичного документа в "родительской" записи. А теперь по поводу - "remote view, или связанные таблицы"...
Зачем использовать связанные таблицы? Можно, совершенно спокойно, не использовать НИ ОДНОЙ реляции. Вы верно предполагаете, в таблицах (например - Журнал событий) хранятся ID таблиц-справочников, НО... визуально, в ФОРМЕ СОБЫТИЙ отображается НЕ САМА ТАБЛИЦА перечня событий, а SQL-запрос, формируемый на основании этой таблицы + вложенные запросы из таблиц-справочников... ДЛЯ отображения в CURSOR истинных наименований из справочников. Эту же технологию можно использовать и в формах первичных документов.
SQL и клиент-сервер, в "чистом" виде.
Вы согласны?
Знаете, у программистов, почти как у ...... - есть свои маленькие тайны... :-) А пока - есть только "пиратские снимки будущего движка".
С уважением, Виктор.
Здравствуйте Виктор.
На мой взгляд, и опыт разработки проектов бухгалтерского и оперативного учета подтверждает это мнение, правильние разделять эти виды учета простейший аргумент это стоимость и сохранность инвестиций в ПО наша практика показывает что качественно сделанный софт по оперативному учету может проработаь лет пять без участия разработчика, а бухгалтерский требует регулярных изменений. Далее если наращивать систему до управленческого учета(учет затрат, обектов, производства) то схема получается в принципе не жизне способная.
С уважением Максим.
Угу. Можно и без SQL сервера, тоже. И вообще все в тетрадочку писать...Зачем использовать связанные таблицы? Можно, совершенно спокойно, не использовать НИ ОДНОЙ реляции.Я что то не пойму Виктор Вы прикидываетесь дурачком или ...Под понятием "связанные таблицы" в многоформатных системах УБД я, как и многие другие подразумеваю связь с таблицами из другой базы, как правило друго формата, а Вы что?Зачем использовать связанные таблицы?
Кстати, о Ваших рассуждениях о способах храения информации ... (свои комментарии опускаю)....
Да будет Вам известно, что тот же MS SQL имеет внутренний механизм оптимизации к доступу данных он очень сильно завязан на ряд объектов. В частности, на определение первичных и вторичных ключей, наличия связей в таблицах и т.д.
Но если Вы действительно хотите обеспечить многоплатформенность то дам вам один совет - одинственный способ обеспечить безпроблемный переход от сервера к серверу это вызов процедур, а не таблиц. Т.е сохраненная процедура на сервере должна выдавать вам некий набор данных и обновления надо проводить через другую процедуру. Тем самы вы сможете реализовать систему на любом "взрослом" сервере, начиная с Oracle, включая MS SQL и Sybase, в том числе и PostGres. Но к сожалению расходы на создание таких объектов очень велики.... без постоянного сопровождения. Это будет точнее.Далее если наращивать систему до управленческого учета(учет затрат, обектов, производства) то схема получается в принципе не жизне способная.
Последний раз редактировалось Dracosha Andrew; 28.11.2003 в 09:28.
Всех благ!!!
Чувелёв Андрей
ps: Всё вышеизложенное является моим частным мнением и не может претендовать на полноту изложения.
Добрый день, Максим!
До определенного времени и я так считал, однако после долгих размышлений и полагаясь на свой, не такой уж долгий (каких-то 15 лет), опыт в практической бухгалтерии, управлении предприятием и программировании сделал некоторые выводы, позволяющие, ИМХО, вполне огранично "приживить разнородные ткани" без последующего их "отторжения".
Вот, кратко, некоторые:
1. модули (напр. - план счетов, дерево проводок, ...) бух_учета и модули обеспечивающие безусловное исполнение глобального механизма управления программой жестко "зашиты" в ядро ПО;
2. модуль добавления, изменения таблиц в базе данных - в открытом классе (т.е. есть возможность редактирования и ДОБАВЛЕНИЯ новых таблиц);
3. формы первичных(учетных) документов для СОБЫТИЙ, как бухгалтерских так и для управленческих - в открытом классе (т.е. есть возможность редактирования и ДОБАВЛЕНИЯ новых форм;
4. проект имеет одну из особенностей - в ЛЮБОЙ момент группу первичных документов управленческого характера можно привязать (или исключить) к бухгалтерскому учету и типовым проводкам или изменив строки проводки не нужно заново ПЕРЕПРОВОДИТЬ или создавать операции, их в программе просто НЕТ, а формирование БУХГАЛТЕРСКИХ оборотов, баланса, ... выполняется по сумме события и ОБРАБОТКЕ ID (ключа) проводки события, ссылающемуся на ID (ключ) в строках проводки ДЕРЕВА ПРОВОДОК. Скажем бухгалтер создал проводку Дт 60 (формула /6*5) Кт 51 - "списаны оплаченные услуги в затраты", вбивал с января по май платежки, создавал и проводил в журнале операций, а с 1 июня "задним числом, с 1 января" ввели ставку НДС=30% (что у нас вполне возможно). Все, у бухгалтера истерика. При моем решении достаточно изменить формулу в проводке ИЛИ привязать к этой группе документов (платежки за услуги) новую проводку с необходимой формулой, т.е. "ПРАВИЛА ИГРЫ" изменяются всего-лишь в одном, КЛЮЧЕВОМ месте, что автоматически приводит к "новому" формированию отчетности;
5. исходя из п.4 :
- изменения в бух.учете корректировать гораздо легче, а значит основные усилия можно направить на наращивание форм открытого класса управленческого учета
- оба учета существуют в едином "жизненном пространстве" не мешая, а скорее дополняя друг друга;
6. отчетные формы формируются методом вставки данных в заранее созданные WORD-шаблоны, что позволяет практически любому пользователю легко внести изменения в документ-шаблон.
... Это далеко не все пункты...
И еще, здесь-же позволю себе ответить на некоторые высказывания Dracosha Andrew
Ну..., гением я, конечно, себя не считаю..., хотя-бы из скромности... :-)
А я еще ЗНАЮ, в дополнение к тому, что Вы ПОДРАЗУМЕВАЕТЕ:
"связанные таблицы" - реляционная модель в базе данных, безусловным правилом которой является целостность первичных ключей таблиц, связанных между собой по первичным, имеющим ОДИНАКОВЫЙ ФОРМАТ, ключам и используемым для хранения, обработки данных, а также возможного ВЕРТИКАЛЬНОГО ИЛИ ГОРИЗОНТАЛЬНОГО РАСЩЕПЛЕНИЯ таблицы. Нормализация таблиц приветствуется.
А теперь, вдумайтесь в Ваши фразы "связь с таблицами из другой базы" и "как правило друго формата"! ???
Не уверен, что "и многие другие" так подразумевают... :-)
Будете разрушать основополагающий принцип целостности первичных ключей?
А вот здесь Вы уже пытаетесь мне рассказать о том, про что я Вас вроде не спрашивал. ;-) Читайте выше... ;-)
С уважением, Виктор.
Это Ваши слова?Зачем использовать связанные таблицы? Можно, совершенно спокойно, не использовать НИ ОДНОЙ реляции.И это Ваши слова?А я еще ЗНАЮ, в дополнение к тому, что Вы ПОДРАЗУМЕВАЕТЕ: "связанные таблицы" - реляционная модель в базе данных, безусловным правилом которой является целостность первичных ключей таблиц, связанных между собой по первичным, имеющим ОДИНАКОВЫЙ ФОРМАТ, ключам и используемым для хранения, обработки данных, а также возможного ВЕРТИКАЛЬНОГО ИЛИ ГОРИЗОНТАЛЬНОГО РАСЩЕПЛЕНИЯ таблицыЭто мои слова. Прочитайте внимательно, что Вы написали и станет ясно, что Вы ничего не написали. Только искуственно подогрваете интерес к себе или своему продукту я не знаю. Пожалуй я не стану больше отвечать в этом топике. Зачем плодить сущности сверз необходимостей?Знаю. Только то что Вы собираетесь прикручивать это remote view, или связанные таблицы. Это вы весю прелесть SQL погубите.
Всех благ!!!
Чувелёв Андрей
ps: Всё вышеизложенное является моим частным мнением и не может претендовать на полноту изложения.
Здравствуйте Виктор.
Приживить можно что угодно вопрос зачем? Вы сами пишите «разнородные ткани», так давайте оставим в покое эти ткани и не будем пришивать ухо к за…. Признаться за последние 10 лет порядком надоели баталии по поводу автоматизации предприятии, причем речь идет о элементарной автоматизации примитивных бизнес процессов. Я считаю что разработчики идут на поводу у мало грамотных бухгалтеров для которых важно доказать свою важность на предприятии. Зачем все усложнять ? Бухгалтерский учет вторичен. Зачем интегрировать его в оперативный? Разделяя учет я снижаю стоимость владения продуктом (делаю его привлекательным для широких масс). Усложняя продукт, мы сужаем круг его потенциальных потребителей, а значит и наших клиентов J. Я понимаю что такое «открытый класс», а мои клиенты нет. Обратите внимание что на рынке нет качественного продукта который можно считать стандартом и удовлетворяющего большинство пользователей, 1С я в расчет не беру так как приличной массовой конфигурации я не видел, все требуют доводки, как и ваш продукт, а конкурировать с 1С на ее поле довольно глупо.
Здравствуйте, maxx!
"Разнородные ткани" - для тех, кто плохо знает предмет (например, к ЧЕМУ надо пришивать ухо, а к ЧЕМУ за….).
Спрашиваете зачем?
Ну хотя-бы затем, что без "вторичного" бух. учета Вы не будете получать полноценный "первичный"... В лучшем случае - суррогат, формируемый, что вполне ВОЗМОЖНО, "мало грамотными", в любом учете, управленцами... Когда менеджеру задаешь, невинный вопрос о гудвиле (вполне управленческий термин по GAAP) предприятия, которым он управляет, в ответ видишь тупое выражение процесса мыслительного напряжения.
"...Разделяя учет я снижаю стоимость владения продуктом" - это эфимерная, одноразовая выгода. Вы, умалчивая, увеличиваете ЗАТРАТЫ на создание ИНФОРМАЦИИ, заставляя пользователей ДУБЛИРОВАТЬ ее в разных программых продуктах...
"...Усложняя продукт, мы сужаем круг его потенциальных потребителей" - но почему-то, ИМХО, происходит обратное - посмотрите на продукты той же Microsoft... Да и пользователей работающих в среде DOS в офисах давно не наблюдается...
Неужели непонятно... А Вашим клиентам и не надо понимать "что такое «открытый класс»" - люди сегодня привыкли "покупать готовое платье" и купив автомобиль они совершенно не обязаны знать как конструктивно и технологически устроены ABS, кондиционер или двигатель внутреннего сгорания. А для обслуживания, ремонта, тюнинга существует СЕРВИС. И если я могу себе позволить купить BMW, то нахожу деньги и на ее содержание. В противном случае - катайся на трамвае (читай - главное оружие автоматизации - КАЛЬКУЛЯТОР... или "ЖЕЛЕЗНЫЙ ФЕЛИКС")
Точно, и это за столько-то лет (1С) на рынке... Значит как в анекдоте, рано или поздно, - доктор сказал в ...., значит в .... :-)
Согласен, доводки и мой продукт требует, но я предпочитаю, накопив определенный запас ЛИЧНОГО (но, никак не мнение бухгалтеров, будь они хоть семи пядей во лбу) опыта, создавать НОВЫЙ продукт, дабы не тянуть "хвосты" не совсем правильных решений прошлых лет.
Это почему-же глупо, maxx? Играть (И ВЫИГРЫВАТЬ) в футбол "на чужом поле" не глупо, а с 1С глупо? Программы как боксеры - тоже СТАРЕЮТ.... и их просто "избивают"... даже на их "поле". Что за фифочка такая - 1С? Вы не поверите, но вполне получается (и даже "под фанфары") ВЫШИБАТЬ эту "вездесущую ГАВРИЛУ" из некоторых сегментов рынка. Не мое мнение, но - и это только начало.
И еще, в ответ на сообщение Чувелова Андрея:
Уважаемый Андрей!
Точно, МОИ СЛОВА!!! И если я написал, что можно НЕ ИСПОЛЬЗОВАТЬ ни одной реляции, то я в ЭТОМ УВЕРЕН. Например, Вам когда- нибудь встречалось такое понятие - "сетевая база данных", построенная на так называемых узловых связях? Правда, это ближе к UNIX-подобным системам.
А вот КАКИМИ методами это реализуется, я объяснять никому НЕ ОБЯЗАН. Сегодня, информация - дорожающий товар на рынке... ;-)
За-а-а-чем? Настоящий топик просмотрело - 86...
Извините, совершенно НЕ РЕКЛАМА..., но мой сайт в ноябре посетили - 15 762 (россиян - 8 770), скачав - 9,9 Гб программного обеспечения.
Надеюсь, Вы НЕ скажете, что всех этих людей я "заманил" перепиской в KLERK.RU :-) :-)
С уважением, Виктор.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
