"Client" или "Workstation"?

Программы на Clarion, шаблоны, библиотеки и пр.

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Ответить
Гость

Сообщение Гость »

Hello clalist,

Хочу посоветоваться!

Есть потребность написания системы, собирающей информацию из удаленных подразделений.
Для начала это должно работать посредством одной дискеты или, например, одного Zip-а, чтобы пользователя не приходилось многому учить (запись CD, работа с модемом и т.д.)
(сразу уточню, удаление значительное - до 10-20 км, и деньги на сеть, или там другие навороченные способы связи заказчик тратить не готов, для него проще послать машину (которая БИ-БИ, а не с кнопочками :)

Есть на этот счет идея, может быть и очевидная, но в моем личном опыте ранее не использовавшаяся:

1. Будет Staff Server) - его функции управление основными базами
2. Будет Staff Workstation (или лучше назвать Staff Client ? - посоветуйте какое название БОЛЕЕ ПРАВИЛЬНО? :D)
функции Staff Workstation или Staff Client - заполнение табеля

Соответственно в сторону клиента должна идти информация об изменениях в штатном расписании, персонале и справочниках, а обратно - заполненый табель за определенный промежуток времени

3. Для всех действий пользователя на стороне сервера фиксируется их дата и время. Тогда при переносе данных на рабочую станцию (клиент) в подразделении будет делаться выборка только тех изменений, что еще на рабочей станции не переносились.

Объем информации в обратную сторону ограничен (одна таблица - табель) и с ним проблем не будет.

4. Server будет скорее всего работать на сетевых базах Pervasive (Btrieve) под имеющимся сервером Novell Netware 6.0.
WorkStation - логично планировать для работы с локальными базами того же формата

Если у кого-то что-то из изложенного вызвало приступ смеха или бурное негодование - то УБЕДИТЕЛЬНО прошу высказаться :D
У меня опыт небольшой, а к критике отношусь положительно.
Так же учту любые рекомендации как по всей архитектуре, так и отдельным вопросам связанным с выбором железа (передача данных), и программного обеспечения (сервер, СУБД)

:)


З.Ы. (p.s.)
-------------------
Staff Server(R)
Staff Workstation(R)
-------------------
Названия официально ПОКА не зарегистрированы, и хотелось бы знать - слышал ли кто-нибудь их ранее.
:D
(да ладно, мы не жадные и нос не задираем :))


--
Best regards,
Иван mailto:shkmail@inbox.ru


(Добавление)

2. Правильнее, на мой взгляд, назвать клиентом.
Соответственно в сторону клиента должна идти информация об изменениях в штатном расписании, персонале и справочниках, а обратно - заполненый табель за определенный промежуток времени
Кто имеет право менять штатное? Только "сервер" или любой из "клиентов"?

3. А если батарейка в часах села?
А если по второму разу решили одни и те же данные засунуть?
А если решили старые данные засунуть после новых?

Скорее всего, нужно хранить и номер версии базы. Привязка по времени без time-server - это явная угроза логической целостности базы.
Объем информации в обратную сторону ограничен (одна таблица - табель) и с ним проблем не будет.
Так не бывает - чтобы без проблем. :):):)

4. Т.к. обмен будет вестись через промежуточный протокол обмена, то, по большому счету, совпадения форматов хранения необязательно.
Я бы выбирал максимально "необслуживаемые" форматы, т.е. те, которые не требуют вмешательства администратора БД ни при инсталляции, ни при работе. Вроде как Btrieve - именно из таких.
Если у кого-то что-то из изложенного вызвало приступ смеха или бурное негодование - то УБЕДИТЕЛЬНО прошу высказаться :D
Ну нет, глупостей сказано не было :) Да и слов написано не много ;););)
У меня опыт небольшой, а к критике отношусь положительно.
Так же учту любые рекомендации как по всей архитектуре, так и отдельным вопросам связанным с выбором железа (передача данных), и программного обеспечения (сервер, СУБД)
Вопросы, которые должны быть продуманы заранее:
1. Система именования каждого рабочего места.
2. Система версий БД
3. Система подтверждений о доставке.
4. Возможность отката изменений.
5. Отслеживание !!!удалений!!! - очень непрозрачный вопрос.
особенно для каскадных удалений.
6. Система генерации глобально уникального PrimaryKey на каждом рабочем месте для каждой таблицы.
7. Система аудита пользователей системы.
8. Все операции по обмену (отгрузка-загрузка данных, архивирование и т.п.) должны быть встроены в саму систему. Никаких сторонних программ не должно участвовать в процессе. Из архиваторов - могу порекомендовать zlib.dll в обрамлении от Ю.Философова.
9. В качестве перемещаемого носителя, IMHO, лучше всего использовать флэшки. Прочие носители недостаточно долговечны и устойчивы к внешним воздействиям.
10. Система контроля версий самой программы.
11. Система контроля и конвертации структуры БД. Рекомендую DC от Вадима Синявского (стоит своих денег и даже более того).

Ну, остальное коллеги подскажут. Если что-то не очень ясно написал - спрашивай.

С уважением,
Владимир Смелик vovs@bigfoot.com


(Добавление)

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

4. Я предпочитаю производить выгрузку не рабочими файлами БД, а посредством обычных ASCII-файлов формата BASIC.
Их можно использовать и для других подобных задач или, в крайнем случае, просто распечатать и ввести данные вручную.
Да и просто в случае какого-либо сбоя спокойно можно посмотреть эти данные. И "жмуться" в архивы они хорошо.
Экспорт/импорт очень легок и прост. В простейшем случае - достаточно одной процедуры для экспорта/импорта любого такого файла.
Еще одно преимущество - независимость от формата БД синхронизируемых баз.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru


(Добавление)
Лучше не "завязываться" на дату/время - потенциально много ситуаций, могущих привести к неполной выгрузке изменений.
Это зависит от задачи. Если имеем, например, пункты видеопроката кассет или торговую точку в магазине, где работа осуществляется в реальном режиме времени и исправления введенной информации принципиально запрещены, то вполне логично использовать системную дату/время. Конечно, нужно перестраховаться от случаев "слета" часов. Например, встроить функцию смены даты у всех документов в случае ввода "передним" числом и т.п.

Если говорим про зарплату (вроде в вопросе прозвучали мотивы), то у меня долго и без какого-либо вмешательства работала система с разделением базы на отдельные физические таблицы для подразделений. В этом случае никакой выгрузки-загрузки не требовалось (только в случае переводов работников), копировались месячные файлы, запускался перерасчет на центральной машине (для заполнения долговременных архивов). Отчеты строились автоматически на основании справочника подразделений.

Если требуется именно синхронизация, то без флажков в базе не обойтись.
Кроме этого, потребуется специальное поле-идентификатор подразделения, в котором запись создана.
Еще одно преимущество - независимость от формата БД синхронизируемых баз.
Присоединямс :-)) Еще можно добавить, что все это хорошо накрывается шаблоном, если придерживаться правила для каждой таблицы создавать Primary-ключ по идентификатору.

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru


(Добавление)
Отчеты строились автоматически на основании справочника подразделений.
То-то и оно. Заказчик требует, чтобы была возможность изменения штатного расписания (самым причудливым образом) в любой момент времени.

Предприятие большое (относительно, может быть, :) - водоканал 300-тысячного города.
В качестве примера перевода работника заказчик поясняет, что один и тот же человек - например шофер - может иметь и основное место работы, и временное: например на время ремонта автотехники.
Отсюда следует, что изменения происходят не только в распределении работников по подразделениям, но и в изменении порядка учета их рабочего времени.

Так что синхронизировать базы придется в среднем раз в две недели.
Если требуется именно синхронизация, то без флажков в базе не обойтись.
Кроме этого, потребуется специальное поле-идентификатор подразделения, в котором запись создана.
Нет... все изменения в основных базах происходят только в
Staff Server-е.
Staff Client испозуется только для _Заполнения_ табеля.
Присоединямс :D Еще можно добавить, что все это хорошо накрывается шаблоном, если придерживаться правила для каждой таблицы создавать Primary-ключ по идентификатору.
Хм... и для сервера и для клиента планируется использовать Pervasive Btrieve. (не SQL)

и потом тут Владимир Смелик (vovs@bigfoot.com) отвечал:

"Я бы выбирал максимально "необслуживаемые" форматы, т.е. те, которые не требуют вмешательства администратора БД ни при инсталляции, ни при работе. Вроде как Btrieve - именно из таких."

тогда почему бы не использовать для синхронизации такие же базы?

И еще: не совсем понятны рассуждения про Primary ключ... :(
Я так понимаю:
На сервере (в смысле приложения-сервера) базы обслуживаются.
Там то и устанавлювается "глобально-уникальное" Primary поле с автоинкрементом.
А потом уже, при синхронизации на клиента ТА ЖЕ база по структуре будет иметь ТЕ ЖЕ поля (в т.ч. и Primary), но уже не с автоинкрементом, а устанавливаемым __вручную__.

И еще :)
Предполагается, что локальные базы разных подразделений будут одинаковыми только по структуре. Т.е. синхнронизация будет проводится только теми записями. которые имеют отношение к данному подразделению.

Спасибо за комментарии!
Вы не представляете, как я вам (всем) благодарен :D

--
Best regards,
Иван

(Добавление)
тогда почему бы не использовать для синхронизации такие же базы?
Объясняю.
Передача данных через промежуточный носитель - очень тонкая операция. Количество вариантов сбоев очень велико. Например, новые дискеты в пачке по моему опыту дают до 30% сбоев. Т.е. 3 дискеты из 10 могут не читаться на другом приводе. Или - частично не читаться. Если не будет прочитан (или будет, но неправильно) хоть один сектор из файла сложного формата, то будут утеряны ВСЕ передаваемые данные. Текстовый же промежуточный формат позволит хоть в какой-то мере и исправить, и локализовать ошибки передачи без дополнительных средств.
А потом уже, при синхронизации на клиента ТА ЖЕ база по структуре будет иметь ТЕ ЖЕ поля (в т.ч. и Primary), но уже не с автоинкрементом, а устанавливаемым __вручную__.
Избави бог тебя от ручного формирования PK. Как только в это узкое место влезет тупой юзер грязными руками, так сразу начнется геморрой.
Насколько я понял, будет 2 типа данных:
1. Редактируемые только на сервере.
2. Как будто бы редактируемые только на клиенте. На самом деле они будут редактироваться и там, и там.

Данные 1-го типа могут иметь простой автоинкриментный PK, формируемый серверным приложением.
А вот 2-го типа... Тут должна быть история записи хотя бы на уровне создателя. Т.е. PK - двухкомпонентный. 1-е поле - ID либо юзера, либо клиента (автора), 2-е - автонумеруемое. И это - самое поверхностное решение. В идеале можно навернуть в начало PK еще одно поле - ID потребителя данных (целевого подразделения; может совпадать по значению с полем номер 1).
Предполагается, что локальные базы разных подразделений будут одинаковыми только по структуре. Т.е. синхнронизация будет проводится только теми записями. которые имеют отношение к данному подразделению.
Ну да. Если ты будешь заранее знать, что какому подразделению передается, организуешь отслеживаемую систему переводов из подразделения в подразделение с сохранением истории и т.п..

В общем, над структурой думать и думать :)
И чем больше ситуаций планируется обслуживать, тем сложнее будет структура. Скорее всего, это будет какая-то многомерная версия singletree. Третье измерение - время жизни ветки.

Для осознания проблемы - ситуация:
Меняется название подразделения. Нужно выдать человеку справку за период +- 3 месяца от момента смены названия.
Т.е. в справке должно присутствовать 2 названия.

Другой класс ситуаций - объединение, разукрупнение, переподчинение подразделений. Для полного кайфа - все сразу и со сменой названий ;)

Третий класс - совмещение, замещение, перевод, увольнение, прием на работу и прочее движение персонала.

PS: Ты меня, конечно, слушай, но ориентируйся по местным условиям. Лучше всего - заранее приземли заказчика, чтобы он не раскатывал губу. Иначе - в погоне за универсализмом ты пролетишь по времени.
Я бы брал такую задачу минимум на пол-года разработки плюс еще 3 месяца на внедрение и опытную эксплуатацию.
Полное внедрение - через год. Командой минимум из трех человек :)


С уважением,
Владимир Смелик vovs@bigfoot.com

Большое спасибо за советы.
Полное внедрение - через год. Командой минимум из трех человек :)
В общем оно так и планируется - полгода на разработку и далее сопровождение.

А в отношении железа - в этом городе обслуживать железо просто некому и максимум на что способен пользователь - всунуть-высунуть дискету.
Так что система должна быть максимально универсальной и устойчивой к непредсказуемым действиям пользователей.

(А мотаться каждый месяц через пол-России ой как не хочется :)))

--
Взаимно :)
Иван

(Добавление)
Нет... все изменения в основных базах происходят только в Staff Server-е.
Staff Client испозуется только для _Заполнения_ табеля.
То есть считаться все будет на основной машине (локалке), а в подразделениях расчетчики отсутствуют?
Если так, то зачем нужно что-то синхронизировать? Сделать им небольшую программульку для ввода табеля в подразделениях. Штатное в виде файла обновлять. Вроде как после передачи табеля голове никакой ценности эта информация уже не имеет.
Не знаю всех тонкостей, смотри сам, думается для такой задачи попроще нужно быть :D
Хм... и для сервера и для клиента планируется использовать Pervasive Btrieve. (не SQL)
А зачем, вроде как Btrieve не бесплатный продукт, или я ошибаюсь? Не проще обычный tps или dat взять на декстопную задачу?
И еще: не совсем понятны рассуждения про Primary ключ... :(
Просто все - имея Primary-ключ, однозначно идентифицируем каждую запись в таблице, а значит полностью контролируем базу.

С уважением,
Вячеслав Черников
тогда почему бы не использовать для синхронизации такие же базы?
Разбор полетов будет не самым прозрачным. Для ASCII хватит Блокнота и принтера.

Еще неплохой вариант XML.
Предполагается, что локальные базы разных подразделений будут одинаковыми только по структуре. Т.е. синхнронизация будет проводится только теми записями. которые имеют отношение к данному подразделению.
Как я понимаю основная тема синхронизации - это перемещения работника.
Структура предприятия и нормативы меняются редко. Причем эти перемещения придут "сверху" и с опозданием до 2-х недель. И надо понять, как вести табель, когда фактически работник переведен, а изменения в базу еще не пришли. ИМХО без перевода на клиенте по бумаге или звонку не обойтись и здесь будет источник постоянных конфликтов клиента и центра.

WBR, Nick Tsigouro. MailTo:Nick@arsis.ru


(Добавление)

Послушал я, послушал и решил встрянуть...
Это зависит от задачи.
100% прав! :)

И так, имеется Задача: создать систему синхронизации данных между
сервером и клиентами при доставке данных курьером.
Считаю:
- Носитель.
- Flash-память (надёжна, практически вечна, требует читателей,
ограничено по объёму,дорого при больших объемах >512М)
- носимый HD (надёжен, ресурс 10-20 лет, требует USB/лучше USB-2/,
по цене при объемах от 20М пока не имеет конкурентов)
- MO диски, ZIP и т.п. (менее надёжна чем предыдущие, требует
дисководов, ограничена по объему)
Вероятно 250М объема будет достаточно в подавляющем большинстве
случаев.
- Секретность.
- Если вам всё равно, то для доставки можно использовать любой
формат, в т.ч. и текстовый. Заявления, типа "что если будет
потерян кластер, то у НЕтекстовых будет потеряно всё" и т.п.
считаю необдуманными. Тут должен действовать принцип транзакции:
или вы принесли полностью срез базы (пакет изменений) или ничего.
При любом крахе информации вам в ЛЮБОМ случае придётся посылать
курьера ещё раз. :) При заливке части информации, совокупная база
не может считаться целостной (достоверной), т.е. она будет
практически бесполезна для пользователя.
- Если же требуется сохранность инфы от утечки (носитель утерян
или украден), то без шифрации не обойтись. Можно использовать
разные варианты. Например, один из самых простых, это использовать
возможности OS Windows и NTFS по шифрации файлов. Для клариона
также удобно использовать TPS с паролем. Длину пароля необходимо
брать не менее 8-и случайных символов или чисел (лучше 12 и более).
Защита информации на АРМах и сервере - общеизвестна и об этом не
раз и в ClaList говорилось.
- База.
В принципе структура базы действительно "зависит от задачи".
Структура может быть индентичной как для сервера так и для
клиента, но может и отличаться.
Некоторое "общее решение" может быть таким:
- ID записи (уникально)
- ID подразделения
- ID записи на клиенте (используется на сервере, на клиенте
может отсутствовать или =0 или использоваться для
блокирования изменений для записей с сервера)
- ID пользователя (оптимально для каждого пользователя, даже
если они работают на одном АРМе, должен быть свой ИД и пароль)
- Дата/время внесения/изменения записи (не представляю, как
без инета можно иметь одинаковое время на удалённых клиентах!)
- время относительно GMT (для учёта зимнее/летние, смены пояса)
- Флаг: удалено (вероятно на клиенте физическое удаление записей
должно быть только после подтверждения с сервера
/подтверждения удаления записи/)
- прочее...
В принципе для заливки с клиента вполне достаточно "ID записи" и
"ID подразделения", т.к. это уникально. Остальные - как
вспомогательные. Кстати, надеюсь что все знают, что ИД это не
обязательно LONG или SIGNED и т.п., это может быть любое уникальное
значение для данного класса (группы). :)
В общем, структура баз - это просто. Проблемы будут в другом - в
логической целостности. Например, есть список профессий.
В разных подразделениях одновременно добавили "Слесарь какой-нибудь".
Да ещё с ошибками! При слиянии это необходимо выявлять.
Как? - не знаю :( Наверное или закладывать крутую систему
алгоритмов для импорта данных или вводить очень жесткие правила и
ограничения на клиентах или... отказаться от "порционного" слияния :)

Чесно говоря, я не очень понимаю, почему нельзя использовать интернет.
Я не думаю, что это будет принципиально дороже курьера. Да и решений
сейчас существует много: "телефонный" инет, GPRS, радиомодемы, модемы
для энергосетей и т.д. и т.п.
Да даже если у вас ВООБЩЕ нет доступа в инет, то и тогда всё
решается - телефоны то есть на каждом участке! И не нужно никакого
слияния - прямой доступ к серверу. Практически при тех же затратах, вы
лишаетесь головной боли от курьеров, сложностей по слиянию и приобретаете
прелести всегда актуальной БД.
Передача данных через промежуточный носитель - очень тонкая операция. Количество вариантов сбоев очень велико. Например, новые дискеты в пачке по моему опыту дают до 30% сбоев. Т.е. 3 дискеты из 10 могут не читаться на другом приводе. Или - частично не читаться.
А ты какие дискеты вспомнил? Трех дюймовые или пяти? :))
Хм, интересно, а сейчас хоть кто-нибуть ещё пользуется дискетами?
Я свои выкинул два года назад. Вместе с дисководами... :))
Хм, ещё раз. Вот ZIP ещё стоит, но когда я им пользовался последний
раз, уже и не помню. Точно в прошлом году, но какой месяц?!
Если не будет прочитан (или будет, но неправильно) хоть один сектор из файла сложного формата, то будут утеряны ВСЕ передаваемые данные. Текстовый же промежуточный формат позволит хоть в какой-то мере и исправить, и локализовать ошибки передачи без дополнительных средств.
Думаю ты не прав. Вариант "сщас залезу и поправлю" надо исключить
изначально. Для него нет предпосылок ни технических, ни программных,
а административно вообще должно быть табу.
Полное внедрение - через год. Командой минимум из трех человек :)
А ещё можно поискать готовое решение :)) Сейчас кадровых прог (или по зарплате) как собак нерезанных! :)
То есть считаться все будет на основной машине (локалке), а в подразделениях расчетчики отсутствуют?
Если так, то зачем нужно что-то синхронизировать? Сделать им небольшую программульку для ввода табеля в подразделениях. Штатное в виде файла обновлять. Вроде как после передачи табеля голове никакой ценности эта информация уже не имеет.
Не знаю всех тонкостей, смотри сам, думается для такой задачи попроще нужно быть :D

Полностью поддерживаю. Если стоит задача табельного учёта,
то во всех кадровых программках(нормальных) уже давно делается
отдельный блок (модуль) для табельщика (ведение табеля /учета
времени/). Табельщику больше и не положено, - всё остальное
заполняется в отделе кадров на основе первичных документов.
В таком случае всё значительно упрощается, - одна единственная
изменяемая таблица. Все остальные "приходят" с сервера и изменению
не подлежат.
Может действительно стоит сначала посмотреть уже имеющиеся на рынке
программы учета? Вполне возможно, что одна из них сможет удовлетворить большую часть потребностей. А остальное уже дописать в виде модулей.
Ну или как минимум, почерпнёшь кучу идей, как надо и как не надо делать... :)

Сергей - chusha@mail333.com ; chusha@hotbox.ru

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

Но я еще об этом не думал :)
Наверное это не сложно.
Может действительно стоит сначала посмотреть уже имеющиеся на рынке программы учета? Вполне возможно, что одна из них сможет удовлетворить большую часть потребностей. А остальное уже дописать в виде модулей.
Ну или как минимум, почерпнёшь кучу идей, как надо и как не надо делать... :)
Этим сейчас и займусь :))
Здесь уже упоминавшаяся _важная_ особенность - именно сбор информации из нескольких удаленных подразделений

--
С уважением,
Ivan
- Flash-память (надёжна, практически вечна, требует читателей,
Не кажи "гоп". В непредвзятых детских руках лелит только на раз-два, если выдергивать без программного отключения девайса. Особенно та, что подешевле - NoName.
- Секретность.
Секретность должно решать независимо от формата.
При заливке части информации, совокупная база не может считаться целостной (достоверной), т.е. она будет практически бесполезна для пользователя.
Не скажи.
Это зависит от задачи.

Табель на пару чел. можно продиктовать по телефону и доввести в центре.
Защита информации на АРМах и сервере - общеизвестна и об этом не
раз и в ClaList говорилось.
Прежде всего должны быть предъявлены требования. Без этого обсуждать защиту бессмыслено.
Наверное или закладывать крутую систему
алгоритмов для импорта данных или вводить очень жесткие правила и
ограничения на клиентах или... отказаться от "порционного" слияния :)
Да нет. Все просто. Нормативно-справочная формируется наверху и рассылается сверху, и система внизу не откроет день, пока не загрузит НСИ. Только это редко удается реализовать на практике. А по жизни - наверно, доввод НСИ на местах и полуручная синхронизация при поступлении НСИ центра. Типа, твой "Слюсарь" это кто? И прием в центре только если при заполнении табеля была использована актуальная НСИ.
Да даже если у вас ВООБЩЕ нет доступа в инет, то и тогда всё
решается - телефоны то есть на каждом участке! И не нужно никакого
слияния - прямой доступ к серверу.

ClarioNet форева.

WBR, Nick Tsigouro
Написал: ClaList(2)
Ответить