Хочу посоветоваться!
Есть потребность написания системы, собирающей информацию из удаленных подразделений.
Для начала это должно работать посредством одной дискеты или, например, одного Zip-а, чтобы пользователя не приходилось многому учить (запись CD, работа с модемом и т.д.)
(сразу уточню, удаление значительное - до 10-20 км, и деньги на сеть, или там другие навороченные способы связи заказчик тратить не готов, для него проще послать машину (которая БИ-БИ, а не с кнопочками
Есть на этот счет идея, может быть и очевидная, но в моем личном опыте ранее не использовавшаяся:
1. Будет Staff Server) - его функции управление основными базами
2. Будет Staff Workstation (или лучше назвать Staff Client ? - посоветуйте какое название БОЛЕЕ ПРАВИЛЬНО? )
функции Staff Workstation или Staff Client - заполнение табеля
Соответственно в сторону клиента должна идти информация об изменениях в штатном расписании, персонале и справочниках, а обратно - заполненый табель за определенный промежуток времени
3. Для всех действий пользователя на стороне сервера фиксируется их дата и время. Тогда при переносе данных на рабочую станцию (клиент) в подразделении будет делаться выборка только тех изменений, что еще на рабочей станции не переносились.
Объем информации в обратную сторону ограничен (одна таблица - табель) и с ним проблем не будет.
4. Server будет скорее всего работать на сетевых базах Pervasive (Btrieve) под имеющимся сервером Novell Netware 6.0.
WorkStation - логично планировать для работы с локальными базами того же формата
Если у кого-то что-то из изложенного вызвало приступ смеха или бурное негодование - то УБЕДИТЕЛЬНО прошу высказаться
У меня опыт небольшой, а к критике отношусь положительно.
Так же учту любые рекомендации как по всей архитектуре, так и отдельным вопросам связанным с выбором железа (передача данных), и программного обеспечения (сервер, СУБД)
З.Ы. (p.s.)
-------------------
Staff Server(R)
Staff Workstation(R)
-------------------
Названия официально ПОКА не зарегистрированы, и хотелось бы знать - слышал ли кто-нибудь их ранее.
(да ладно, мы не жадные и нос не задираем )
--
Best regards,
Иван mailto:shkmail@inbox.ru
(Добавление)
2. Правильнее, на мой взгляд, назвать клиентом.
Кто имеет право менять штатное? Только "сервер" или любой из "клиентов"?Соответственно в сторону клиента должна идти информация об изменениях в штатном расписании, персонале и справочниках, а обратно - заполненый табель за определенный промежуток времени
3. А если батарейка в часах села?
А если по второму разу решили одни и те же данные засунуть?
А если решили старые данные засунуть после новых?
Скорее всего, нужно хранить и номер версии базы. Привязка по времени без time-server - это явная угроза логической целостности базы.
Так не бывает - чтобы без проблем. :):)Объем информации в обратную сторону ограничен (одна таблица - табель) и с ним проблем не будет.
4. Т.к. обмен будет вестись через промежуточный протокол обмена, то, по большому счету, совпадения форматов хранения необязательно.
Я бы выбирал максимально "необслуживаемые" форматы, т.е. те, которые не требуют вмешательства администратора БД ни при инсталляции, ни при работе. Вроде как Btrieve - именно из таких.
Ну нет, глупостей сказано не было Да и слов написано не много ;);)Если у кого-то что-то из изложенного вызвало приступ смеха или бурное негодование - то УБЕДИТЕЛЬНО прошу высказаться
Вопросы, которые должны быть продуманы заранее:У меня опыт небольшой, а к критике отношусь положительно.
Так же учту любые рекомендации как по всей архитектуре, так и отдельным вопросам связанным с выбором железа (передача данных), и программного обеспечения (сервер, СУБД)
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 испозуется только для _Заполнения_ табеля.
Хм... и для сервера и для клиента планируется использовать Pervasive Btrieve. (не SQL)Присоединямс Еще можно добавить, что все это хорошо накрывается шаблоном, если придерживаться правила для каждой таблицы создавать Primary-ключ по идентификатору.
и потом тут Владимир Смелик (vovs@bigfoot.com) отвечал:
"Я бы выбирал максимально "необслуживаемые" форматы, т.е. те, которые не требуют вмешательства администратора БД ни при инсталляции, ни при работе. Вроде как Btrieve - именно из таких."
тогда почему бы не использовать для синхронизации такие же базы?
И еще: не совсем понятны рассуждения про Primary ключ...
Я так понимаю:
На сервере (в смысле приложения-сервера) базы обслуживаются.
Там то и устанавлювается "глобально-уникальное" Primary поле с автоинкрементом.
А потом уже, при синхронизации на клиента ТА ЖЕ база по структуре будет иметь ТЕ ЖЕ поля (в т.ч. и Primary), но уже не с автоинкрементом, а устанавливаемым __вручную__.
И еще
Предполагается, что локальные базы разных подразделений будут одинаковыми только по структуре. Т.е. синхнронизация будет проводится только теми записями. которые имеют отношение к данному подразделению.
Спасибо за комментарии!
Вы не представляете, как я вам (всем) благодарен
--
Best regards,
Иван
(Добавление)
Объясняю.тогда почему бы не использовать для синхронизации такие же базы?
Передача данных через промежуточный носитель - очень тонкая операция. Количество вариантов сбоев очень велико. Например, новые дискеты в пачке по моему опыту дают до 30% сбоев. Т.е. 3 дискеты из 10 могут не читаться на другом приводе. Или - частично не читаться. Если не будет прочитан (или будет, но неправильно) хоть один сектор из файла сложного формата, то будут утеряны ВСЕ передаваемые данные. Текстовый же промежуточный формат позволит хоть в какой-то мере и исправить, и локализовать ошибки передачи без дополнительных средств.
Избави бог тебя от ручного формирования PK. Как только в это узкое место влезет тупой юзер грязными руками, так сразу начнется геморрой.А потом уже, при синхронизации на клиента ТА ЖЕ база по структуре будет иметь ТЕ ЖЕ поля (в т.ч. и Primary), но уже не с автоинкрементом, а устанавливаемым __вручную__.
Насколько я понял, будет 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 испозуется только для _Заполнения_ табеля.
Если так, то зачем нужно что-то синхронизировать? Сделать им небольшую программульку для ввода табеля в подразделениях. Штатное в виде файла обновлять. Вроде как после передачи табеля голове никакой ценности эта информация уже не имеет.
Не знаю всех тонкостей, смотри сам, думается для такой задачи попроще нужно быть
А зачем, вроде как Btrieve не бесплатный продукт, или я ошибаюсь? Не проще обычный tps или dat взять на декстопную задачу?Хм... и для сервера и для клиента планируется использовать Pervasive Btrieve. (не SQL)
Просто все - имея 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 ещё стоит, но когда я им пользовался последний
раз, уже и не помню. Точно в прошлом году, но какой месяц?!
Думаю ты не прав. Вариант "сщас залезу и поправлю" надо исключитьЕсли не будет прочитан (или будет, но неправильно) хоть один сектор из файла сложного формата, то будут утеряны ВСЕ передаваемые данные. Текстовый же промежуточный формат позволит хоть в какой-то мере и исправить, и локализовать ошибки передачи без дополнительных средств.
изначально. Для него нет предпосылок ни технических, ни программных,
а административно вообще должно быть табу.
А ещё можно поискать готовое решение ) Сейчас кадровых прог (или по зарплате) как собак нерезанных!Полное внедрение - через год. Командой минимум из трех человек
То есть считаться все будет на основной машине (локалке), а в подразделениях расчетчики отсутствуют?
Если так, то зачем нужно что-то синхронизировать? Сделать им небольшую программульку для ввода табеля в подразделениях. Штатное в виде файла обновлять. Вроде как после передачи табеля голове никакой ценности эта информация уже не имеет.
Не знаю всех тонкостей, смотри сам, думается для такой задачи попроще нужно быть
Полностью поддерживаю. Если стоит задача табельного учёта,
то во всех кадровых программках(нормальных) уже давно делается
отдельный блок (модуль) для табельщика (ведение табеля /учета
времени/). Табельщику больше и не положено, - всё остальное
заполняется в отделе кадров на основе первичных документов.
В таком случае всё значительно упрощается, - одна единственная
изменяемая таблица. Все остальные "приходят" с сервера и изменению
не подлежат.
Может действительно стоит сначала посмотреть уже имеющиеся на рынке
программы учета? Вполне возможно, что одна из них сможет удовлетворить большую часть потребностей. А остальное уже дописать в виде модулей.
Ну или как минимум, почерпнёшь кучу идей, как надо и как не надо делать...
Сергей - chusha@mail333.com ; chusha@hotbox.ru
(Добавление)
Дело в том, что эта таблица заполняться может (в принципе) и в течении месяца. А затем, непосредственно перед отправкой табеля в центр обработки, вдруг приходит изменение штатного расписания.Все остальные "приходят" с сервера и изменению не подлежат.
Соответственно - нужно учесть ту информацию. что уже есть.
Но я еще об этом не думал
Наверное это не сложно.
Этим сейчас и займусь )Может действительно стоит сначала посмотреть уже имеющиеся на рынке программы учета? Вполне возможно, что одна из них сможет удовлетворить большую часть потребностей. А остальное уже дописать в виде модулей.
Ну или как минимум, почерпнёшь кучу идей, как надо и как не надо делать...
Здесь уже упоминавшаяся _важная_ особенность - именно сбор информации из нескольких удаленных подразделений
--
С уважением,
Ivan
Не кажи "гоп". В непредвзятых детских руках лелит только на раз-два, если выдергивать без программного отключения девайса. Особенно та, что подешевле - NoName.- Flash-память (надёжна, практически вечна, требует читателей,
Секретность должно решать независимо от формата.- Секретность.
Не скажи.При заливке части информации, совокупная база не может считаться целостной (достоверной), т.е. она будет практически бесполезна для пользователя.
Это зависит от задачи.
Табель на пару чел. можно продиктовать по телефону и доввести в центре.
Прежде всего должны быть предъявлены требования. Без этого обсуждать защиту бессмыслено.Защита информации на АРМах и сервере - общеизвестна и об этом не
раз и в ClaList говорилось.
Да нет. Все просто. Нормативно-справочная формируется наверху и рассылается сверху, и система внизу не откроет день, пока не загрузит НСИ. Только это редко удается реализовать на практике. А по жизни - наверно, доввод НСИ на местах и полуручная синхронизация при поступлении НСИ центра. Типа, твой "Слюсарь" это кто? И прием в центре только если при заполнении табеля была использована актуальная НСИ.Наверное или закладывать крутую систему
алгоритмов для импорта данных или вводить очень жесткие правила и
ограничения на клиентах или... отказаться от "порционного" слияния
Да даже если у вас ВООБЩЕ нет доступа в инет, то и тогда всё
решается - телефоны то есть на каждом участке! И не нужно никакого
слияния - прямой доступ к серверу.
ClarioNet форева.
WBR, Nick Tsigouro
Написал: ClaList(2)