DogenА я бы просто постеснялся говорить о системе репликации, работающей на уровне даже ниже, чем язык запросов СУБД. Или я неправильно прочитал процитированное выше краткое описание архитектуры репликатора?
Имхо, ничего постыдного я не вижу, это одна из возможных реализаций репликаций.
У меня создалось впечатление, что здесь звучит нечто странное. В IT-технологиях термин "низкий уровень" в определенных ситуациях применяется не как "плохой", а "ближе к железу". Например, язык Си или Object Pascal более низкого уровня чем SQL, Асемблер более низкого уровня чем Си. В нашем случае, Делфи с доступом на уровне файлов явно более низкого уровня чем уровень СУБД.

DogenЕсли файл реплицируется кусками, то это следует расценить как репликацию изменений файла, и такой способ разумен. А у Вас что, на уровне файловой системы отслеживается изменение документов системы оперативного учета? Хотите отстаивать рациональность названного Вами решения - дайте ссылку на подробное описание, пожалуйста.

В системе учета "единица хранения" - документ . Даже не таблица БД . Улавливаете разницу?.. Документы должны реплицироваться внутренне целостными пакетами данных. Если кто-то считает, что это не так - флаг в руки, умолкаю :)
Насколько я понял из его объяснений все примерно так и происходит. То есть на уровне файловой системы отслеживаются изменения документов. Я несколько раз предлагал сделать репликацию документов с помощью событийного механизма БЭСТа (у документов существуют события Сохранение, Удаление, Проверка и т.д.), но он считает что такой способ работает медленнее. Я не проверял, поэтому спорить не стал.
Я попрошу его дать разъяснения по этому вопросу.

stoomЯ не понимаю как можно вообще файл-сервер системы серьезно обсуждать!? Этож каменный век. Ну отстали люди от жизни. Кирпич форефа. Пусть бегают с кирпичем.
Хорошо спроектированная файловая система даст фору плохо спроектированной клиент-серверной.
По крайней мере просто переключения драйвера доступа недостаточно, клиент-серверная система должна быть спроектирована таковой.

strizhГы-гы. Это шутка ? И где ж Вы, Sheez, увидели сервер СУБД (или хотя-б сервер приложений) в БЭСТ-5 ?
В БЭСТ-5 есть сервер приложений. На данный момент в его функциональных обязанностях имеется отслеживание уровня доступа, технологические операции (индексирование, проверка целостности БД). В следующей версии добавиться использование триггеров и транзакций.

eee3dddГоспода, Вас все время втягивают в обсуждение техничеких тонкостей, в ходе которого выясняется, что систему Вы знаете достаточно слабо и не видели/не знаете возможностей конкурентных решений. Уровень специалистов схож с уровнем программистов 1с 7.7 (особенно, когда только появилась и туда ломанулись ничего не знающие студенты). За счет того, что платформа забирает основной "головняк", программисты уже и не понимают "а в чем могла быть проблема". Вот если бы поработали в "Java+Oracle", а потом переметнулись, то было бы совсем другое видение.

На исследования других систем не остается времени, доисследовать бы когда-нибудь БЭСТ
Насчет знаний системы - наверное, есть какие-то пробелы, имхо, не может один человек с достаточной основательностью знать систему, на разработку которой потрачены сотни и сотни человеко-лет. Какие-то отдельные моменты - да, пожалуйста.
А уровень специалистов имхо невозможно оценить на основании всего лишь одной дискуссии, тем более не затрагивая методов реализации каких-либо вопросов. Хотя, конечно можно представить,что профессиональные разработчики, которые здесь присутсвуют, смогут заткнуть мне, простому консультанту, рот, по реализации какого-либо алгоритма программным способом.

eee3dddМое мнение остается прежним: "БЭСТовцы не знают, чем лучше их продукт." Под продуктом я понимаю платформу на которой разрабатываются решения и сами решения. В ходе дискуссий вы говорите от производства до выгрузки в различные форматы, но мне так и не понятно, чем все-таки лучше. Об 1c/Axapta/Navision/Sap/OEBS/ известно много как хорошего так и плохого, но о БЭСТе слышны лишь доводы технических специалистов, которые выражаются сугубо своей БЭСТовской терминологией. Представьте, что Вы рекламируете директору молочного комбината( крупной оптовой фирме) свой продукт. ЧТО ВЫ ЕМУ СКАЖЕТЕ?
Я наблюдаю, что к сожалению, некоторые доводы некоторые люди просто пропускают мимо ушей.
Когда я говорю о более низкой стоимости владения например - мое мнение, что это кокурентное преимущество. Мне же говорят в ответ, что это не считается
Говорю, что быстро настраивается, или что бухгалтеру(пользователю) проще и понятней пользоваться и обучаться, это опять не считается. Не придется в штате держать программиста, чтобы постоянно что-то подкручивать. Стабильная, быстро работающая без дополнительных телодвижений система. Это маркетинговые заявления и им нельзя доверять?
А какой БЭСТовской терминологией мы выражаемся, что вы не поняли? Давайте, я попробую перевести.

strizhСервер приложений, в контексте разговора об учетной системе, должен выполнять приложения учета
В биллиарде есть такая поговорка - "Должен, но не обязан"
Системные действия описанные выше он также должен делать. Плюс на нем сейчас висит еще ключевая защита, плюс формирование отчетов (отчетная система - Fastreport, источники данных Foxpro 7)

strizhСервер приложений должен уметь запустить (по требованию клиента, или по срабатыванию триггера, или по приходу сообщения на почту, или по времени - добавьте на свой вкус) некое расчетное (учетное) приложение (например, выборку новых данных о продажах отдела N и их загрузку в OLAP-куб отдела маркетинга, или расчет MRP-таблицы для планирования закупок номенклатуры торговой марки M на период с июня по август) и вернуть результат инициатору; сервер приложений также часто выполняет роль посредника, предоставляющего сервисы взаимодействия между разными СУБД, или учетными системами разных производителей, или системами разных уровней управления.

Чем он собственно и занимается. Отчеты я имею ввиду. Может не MRP, но это уже зависит от фантазии автора, создавшего подобный отчет.
Все остальное... Полезные конечно свойства. Я делал отчет который собирал данные и сопоставлял междку собой делая выборку из базы БЭСТ-5 и MS SQL. Вся выборка и обработка сделана в источнике данных написанном на Foxpro, который в свою очередь исполняет сервер приложений.
Кто в этом случае предоставляет сервис взаимодействия одновременно между разными СУБД и учетными системами разеных производителей и системами разных уровней управления?

strizhЕсли на любой нормальной СУБД запустить "индексацию" (хотя такого понятия обычно уже нет - вместо него есть процедуры обслуживания, которые делают, в терминах .dbf-баз, pack, reindex и плюс перегенерацию содержимого таблиц оптимизатора запросов, удаление "мусора" (остатки прибитых сеансов юзеров - временные таблицы, пулы переменных, к примеру, и пр.), то загрузка процессора на сервере ну никак 100% не будет.

Я привык пользоваться термином "индексация". Пусть это называется "обслуживание", принцип действия именно такой как вы описали. На двух процессорном сервере с Ксеонами загрузка может достигать 25% суммарно (распределенные вычисления )

strizhНапример, в PostgreSQL я наблюдаю загрузку до 25%, если запустить vacuumdb --analyze --full. Делать это приходится, по моим наблюдениям, раз в пол-года. А можно вообще настроить autovacuum, или повесить vacuum в cron ежемесячно и забыть о проблеме.
У каждой СУБД свои отличия, недостатки и преимущества по сравнению с другими.

strizhУлавливаете разницу наших с вами понятий про сервер приложений ? За дополнительными сведениями - на iscrasoft.com, к примеру. В этот фреймворк входит сервер приложений.
И в любую из промышленных СУБД (Sybase, MS SQL, Oracle, PostgreSQL, DB2) входит сервер приложений по умолчанию - именно он занимается запуском хранимок (в том числе - учетно-расчетных, процедур взаимодействия, построения наборов данных для отчетов).
На основе субд Foxpro многое из этого также доступно. Кроме сервера приложений пожалуй. Хотя за подробностями следует конечно обратиться в соответствующий раздел форума. Конечно она имеет свои значительные недостатки, но и достоинства у нее есть. Например, некоторые считают, что такая база будет работать побыстрее чем базы на sql.

strizhТ.е. для того, чтобы Вы, как продавец решений на базе БЭСТ, могли называть один из серверных модулей сервером приложений, этот модуль должен, как минимум, уметь выполнять хранимки на процедурном языке (какими являются, например, tsql, plsql, plpgsql, pltcl, java) над базой данных (в данном случае - ваша база на .dbf). Я полагаю, что задачу такого масштаба команда разработчиков фирмы Бэст не осилит никогда.
Их есть у меня. Сервер приложений исполняет хранимые процедуры, написанные в среде Foxpro 7.
В нашей среде это называется "источники данных". Они находятся на сервере в виде файлов. Каждый внедренец или программист знакомый с Foxpro и ознакомившийся с правилами создания источников в состоянии сделать свои источники, который могут выводить отчеты или производить какие-либо действия на объектами БД. На Foxpro пишутся запросы в нотации SQL. Так что, может это в не совсем привычном нам с вами виде, но с определенными допущениями можно сказать, что это и есть "хранимые процедуры".

strizhВ случае БЭСТ-5 "сервер приложений" - не более как костыль к уже давно устаревшей файл-серверной технологии хранения баз данных.
А в свете сказанного мной выше?


strizhЛегче переписать БЭСТ-5 под Oracle :)
Легче? Несколько миллионов строк кода? Ну-ну.

strizh>Говорю, что быстро настраивается, или что бухгалтеру(пользователю) проще и понятней
>пользоваться и обучаться, это опять не считается. Не придется в штате держать программиста,
>чтобы постоянно что-то подкручивать. Стабильная, быстро работающая без дополнительных
>телодвижений система. Это маркетинговые заявления и им нельзя доверять?
Хорошо. Тогда давайте конкретные цифры.
1) Сколько времени у вас занимает развертывание сервера, базы, первоначальная настройка базы + развертывание одного клиентского рабочего места для фирмы - вашего нового клиента ?
2) Сколько занимает времени настройка бухгалтерских процедур проведения документа 1 вида (для ясности - документа отгрузки товара) под конкретный план счетов и конкретные хотелки главбуха ?
3) Сколько времени занимает настройка доступа ко ВСЕЙ системе для одного пользователя (для ясности - начальника службы снабжения) ?
1. Приблизительно:
Установка серверной части из дистрибутива плюс установка пакетов обновлений (Хотфиксов);10-20 минут.
Разворачивание БД; ~3-5 минут
Установка клиентского места. ~5-10 минут
С отловом администратора сети, кофепитием и разговорами о прекрасном думаю от 30 минут до часа.

2. от 1-ой до 5-ти минут - настройка проводок плюс еще столько же если необходимо настроить новую модель калькуляции. Итого около 10 минут максимум. (Сейчас все тайны раскрою, деньги будет брать не за что ) Это проводки описываемые через набор параметров в БЭСТе. Их там штук 50.
Иногда в проводки приходится добавлять плагины. Например, для одной строительной конторы сделали такой плагин, который вычисляет сумму одной из проводок по накладной на списание материалов в зависимости от суммы закрытых нарядов ( или степени готовности объекта, сейчас точно не помню). Тогда подольше, конечно. Но это именно в таком разрезе, когда надо сделать что-то необычное.

3. Не более 5 минут с обсуждениями. Настройка делается элементарно - создается пользователь, создается роль. Для роли задается доступ к модулям или отдельным функциям на просмотр, ввод, редактирование. Все это делается в специальном приложении - Менеджере пользователей и только на сервере (или в терминальном режиме, но на сервере).

Имхо, не совсем показательные примеры. Сейчас большинство программ все это делается элементарно и примерно одинаково, так что надо искать сравнения в других вещах.

strizhГлавное, что сервер приложений iscra умеет запускать бизнес-обработки данных в нужный момент. А какая технология для этого запуска используется - это уже неважно :)

Как я сказал выше сервер приложений БЭСт-5 также умеет это делать. Другое дело, что он это может сделать только по запросу пользователя. Пока. Но, надеюсь, что все еще впереди.

strizhБЭСТ-5 был и останется устаревшей файл-серверной системой с кучей ограничений по производительности, масштабируемости, безопасности и защите информации.
Думаю, такой вывод просто от незнания или нежелания разобраться. Это не обвинение, а вполне понятная позиция. А проблема Компании БЭСТ(и наша тоже) заключается в том, что маркетологи никак не могут донести убедительно до многих, что ПП БЭСТ вполне современные, обладают большими возможностями, могут реально не требуя значительных вложений помогать вести бизнес, используют современные технологии (не все конечно ) и т.д.

strizhОсобенно меня умиляют всякие разговоры об удаленных рабочих местах, пакетной оффлайн-репликации на .dbf и т.д. Блин, точно каменный век, для меня окончившийся лет 7 назад.

Если рынок, пользователи требуют таких решений, значит они будут. Вне зависимости от того каменный это век или постиндустриальный.

strizh
Надо вам удаленное рабочее место - будьте добры сделать хоть какую-нить выделенку. Это ж дешево, даже по сравнению с лицензией на "Win2003 сервер". А дальше - прямой доступ к центральной БД (по ODBC, ADO и пр.)
А разве такое невозможно сделать с БЭСТом? Возможно. Но есть выбор. И это правильно.

strizhКанал падает - при очередном sql-запросе делаем реконнект (а сервер, в случае чего, транзакцию откатит). На слабом канале сразу и оптимальные алгоритмы находятся (типа нефиг пересылать на клиента 100 записей, если можно всего 10 :-)
Это замечательно. Но вне зависимости от транзакций тут могут проблемы с достоверностью данных.

strizhМало того, даже для файл-серверных систем не вижу необходимости в офф-лайн репликациях. Используйте Citrix Meta Frame - и будет счастье.
Спасибо, мы так и делаем. :) И не только такие решения.

strizhГм. Давайте определимся. Сервер приложений - программа, исполняющая код бизнес-логики, к примеру, а не просто его хранящая. Т.е., если есть "источники данных", написанные для Foxpro7 (как я понял, файлы .prg), значит, исполняются они с помощью, как минимум, vfp7.exe и библиотек vfv7r.dll и пр. на виндовой машине, или, если это просто sql-запросы, средствами ODBC-шной библиотеки для VFP от MS или стороннего производителя. Или "источники данных" - это уже компилированные exe-файлы ? В любом случае - где исполняются эти exe ? На клиенте или на сервере ? Не откуда вызываются на запуск, а именно где исполняются ?
Вот выдержка из документации:
При создании отчетов БЭСТ-5 применяется генератор отчетов Fast Report. Для получения данных для отчетов с помощью технологии COM загружается COM-сервер, написанный на Visual Foxpro 7.0. С его помощью создаются объекты, производящие различные действия над данными и возвращающие результирующий набор данных для отчета. Все объекты создаются на основе классов в библиотеках классов (файлы с расширением .vcx и .vct). Все классы в этих файлах хранятся с их исходными кодами и компилируются при сохранении, поэтому после написания собственного класса источника данных никакой перекомпиляции COM-сервера не требуется. Данная технология также обеспечивает наибольшую скорость работы с данными, благодаря использованию оптимизации встроенной в Visual Foxpro.


strizhОтчетная система FastReport рисует картинки по источникам данных, загружая проц на клиенте. А код, выбирающий собственно данные для источников, исполняется на клиенте (для файл-серверных систем), или на сервере (для классических клиент-серверных систем с толстым клиентом)
Загружает процессор. И рисует на клиенте. Получается "классическая" клиент-серверная технология с "толстым" клиентом.