Архитекторы, подскажите, плз.

[vg]

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

Для удалённых контор всего будет сделано 10 форм (пять в этом году, остальное потом). Работа будет растянута на год – полтора. Делать клиентское ПО могут независимые, различные программеры (часть – может и я удалённо).

Думаю сделать так:
1) Под эти 10 подзадач взвести отдельную базу (а лучше отдельно стоящий сервак в DMZ или отдельной подсетке за МСЭ)
2) Клиентское ПО будет актуализировать только эту базу
3) Будет написано дополнительное ПО, которое будет зашедулено на этом серваке, и которое будет актуализировать базы основной инф. системы.

Система получается избыточной, т.к. появляется дополнительная «буферная» база (скорее всего на дополнительном сервере). Но, думаю, что так будет луше и с точки зрения безопасности данных основной инф. системы, и с точки зрения модернизации основной системы, и с точки зрения удобства сторонних разработчиков клиентского и серверного ПО.

Как луше сделать? Спасибо.

[папа Карло]

оффтопик уехал вот сюда.....

http://forum.kamorka.com/viewtopic.php?t=1544

[dima]

Дон-Милс и Лорэнс ? Моя жена учила в том районе язык. Помню только одно - ужасный трафик в обоих направлениях по Дон-Милс (особенно зимой).

По делу. Если клиенты будут только слать отчеты раз в Х времени, то может имеет смысл организовать ftp сервер для них и поставить CuteFtp или другой дружественный ftp client каждому вместо отдельного ПО.

[Yocto]

Раз в квартал?
Сливать на CD и посылать почтой.

[vg]

dima,

то может имеет смысл организовать ftp сервер для них

Может и так. Для клиентов PPP, работающих только по меди (там в тундре у них компьютеры, работающие от дизельных генераторов , Интернета нет) можно обеспечить доступ по ФПТ.

Но вопрос был несколько в другом. Для начала надо решить - нужна ли избыточная "буферная" база на отдельном серваке в ДМЗ? Эта база будет включать только те кортежи, которые актуализируют удалёнщики. Множество кортежей основной инф. системы неизмеримо шире.
Имеется ввиду на отдельно-стоящем серваке, к которому удалёнщики будут конектиться по https (у кого есть инет), или ftp, как ты говоришь (у кого только медная пара + модем+ т.межгород). Вопрос встал потому, что некоторым из наших деятелей непонятно, зачем нужно иметь промежуточный сервак с "буферной" базой. Т.е. та публика предлагает решение более простое:

Клиент -> WAN (https) -> WWW => LAN (актуализация данных баз DB1, ..., DBn на основных серверах S1, ..., Sn в LAN инф.системы ).

Здесь инет-аккауны клиентов пишут сразу в основные базы инф.системы. Мне это не нравится. И с точки зрения безопасности, и с точки зрения этапности разработки, и сточки зрения модернизации проги на WWW при изменении инфраструктуры инф. системы ( DB1, ..., DBn на основных серверах S1, ..., Sn в LAN инф.системы )

Я предлагал схему "избыточную":

Клиент -> WAN (https) -> WWW -> BufDB (SERV <> {S1, ..., Sn}) <= LAN (актуализация данных баз DB1, ..., DBn на основных серверах S1, ..., S2 в LAN инф.системы ).

Здесь также обрати внимание на то, что => в первом варианте меняется на <= во втором варианте.
Это значит, что если в первом варианте прога на WWW пишет в оновные базы, то во втором варианте прога на одном из основных серверов S1,..., Sn забирает (читает) данные из "буферной" базы. Т.е. в этом случае отсутствует звено, когда инет-юзеры "непосредственно" взаимодействуют с основными базами данных инф. системы(где, конечно, инфы -терабайты и подмножество данных о которых мы говорим - мизерное).

Может ты имел ввиду такое?:
Клиент -> WAN (ftp) -> FTP <= LAN (актуализация данных баз DB1, ..., DBn на основных серверах S1, ..., S2 в LAN инф.системы ).

Yocto,

Раз в квартал?
Сливать на CD и посылать почтой.

В точку. Да, пока так и будем делать. Есть ещё некоторые детали, по которым пока только так мы и можем. Но директор хочет модерново.

[dima]

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

Клиеты с интернетом кладут данные на ftp каждый в свое место. Другая программа будет "перемещать" их в RDBMS.

Клиенты без интернета шлют данные по почте в место где данные будут отправлены на ftp или в место где данные "перемещаются" в RDBMS.

Просто.

[Yocto]

Но директор хочет модерново.

Модерново - не есть экономическая категория.
Каждое решение имеет свою цену, не удивлюсь, если самое дешёвое решение не будет самым на данный момент модным.
Впрочем, если директор готов платить за модность, то почему бы и нет...

[vg]

Клиеты с интернетом кладут данные на ftp каждый в свое место. Другая программа будет "перемещать" их в RDBMS.

В принципе - да. Вполне рабочий вариант. Ещё вопрос.... Как считаешь в части формата передачи данных. Ясно, что лучше в ASCI с любой разметкой полей (тэгов). Думаю, ничего не выдумывать, а делать в XML. Как думаешь?

Спасибо.

[vg]

Yocto,

Каждое решение имеет свою цену, не удивлюсь, если самое дешёвое решение не будет самым на данный момент модным.

Вы правы. Долгое время так и будет. Как Вы сказали - CD почтой. Не только для тех, у кого нет internet, но и для тех у кого он есть.
Мне важно было немного охладить свой пыл .... от своих же гениальных идей. Спасибо. С передаче данных "по-модному" - будем думать, работать. Вернее зарабатывать, пока платят.

[dima]

В принципе - да. Вполне рабочий вариант. Ещё вопрос.... Как считаешь в части формата передачи данных. Ясно, что лучше в ASCI с любой разметкой полей (тэгов). Думаю, ничего не выдумывать, а делать в XML. Как думаешь?

Спасибо.

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

Перед посылкой фалы можно зиповать с паролем.

[Lepsik]

Для удалённых контор всего будет сделано 10 форм (пять в этом году, остальное потом). Работа будет растянута на год – полтора. Делать клиентское ПО могут независимые, различные программеры (часть – может и я удалённо).
Как луше сделать? Спасибо.

Как лучше тебе видней. В моем фотоагенстве (где ряд филиалов)
данные шлют или через mdb или через xml.

Я одновременно поддерживаю оба формата (в зависимости от размеров пользователи выбирают).

export/import/replication

через это дело поддерживается.

Очень хорошо у ASA Sybase репликация через дискетки может организована (то бишь через CD) в твоем варианте

[vg]

Я одновременно поддерживаю оба формата (в зависимости от размеров пользователи выбирают).

Логично. Мы в перспективе так и сделаем. Сейчас взял на работу программра, что на VB.NET сделает для mdb.
Сам хочу попробавать с XML. Не могу удержаться. C XML пока не знаю, как получить отчёт в rtf. Должны быть где-то классы или COM, чтобы подсовывать им XML + некую XLS-подобнуб таблицу стилей, а на выходе получать rtf.
Знаю, как получить твёрдые копии в Билдере. Но на этот порочный круг не хочу снова. Хочу только в .NET IDE. Знаешь, как это сделать?

[Lepsik]

А зачем тебе RTF ? И как это связано с XML ?

у ADO есть метод создания xml на основе рекордсета

[vg]

А зачем тебе RTF ? И как это связано с XML ?

На клиентской стороне (удалённые клиенты в тундре) нужно:
1) заполнить формы отчётности
2) сохранить данные в XML (or mdb)
3) переслать данные нам (в мою контору) на CD или модно (фпт, бла-бла-бла)
4) "распечатать" красиво, подписать, поставить печати для пересылки твёрдой копии в другую контору. (нам электронно, в другую контору -заверенные бумаги)

Дык, удобно прям из XML и получать им RTF для печати. И нам было б удобно (уже для наших чиновников), получив от клиента XML, сделать красивый отчёт.

у ADO есть метод создания xml на основе рекордсета

Ну, да у ADO.NET. Можно читать и заливать данные на MS SQL Server. Сам не пробовал пока. Может и у обычного ADO есть. Я не смотрел.

[Lepsik]

современные репорт-компонент могут подключать xml, mdb и заполнять данные в шаблоне.

А потом хошь на принтер - хошь в PDF, RTF, HTML.....