OTigerНу ка, раскажите мне про завод, который удален от населенного пункта на 500 км. Покажите хоть один такой на карте? Мне в принципе интересно, где люди то, работающие на нем живут? За 500 км. кажный день ездят?:)
Причем тут завод ? К примеру - таможенный пост на границе РФ. На китайской границе действительно до 500 км. Работают смены, которые меняются каждые 2 недели, едут на машинах, везя с собой запас пищи, информацию и прочее. Через пост идет поток машин с декларациями, которые необходимо пускать в центр, одновременно получая платежки по их оплате. Ораклисты здорово обломались на таможне со своей концепцией централизованных серверов, когда всплыли эти посты, коих около 700 штук и через которых идет основной грузопоток товара в РФ :)

Уважаемый OTiger, любая РСУБД позволяет сделать удаленный доступ. Это только вопрос грамотного проектирования клиентской части. Однако не любая РСУБД готова быстренько развернуть распределенные базы данных с обновлением по оффлайн через плохие каналы связи, а то и без них вообще. Ну а насчет Ваших рассуждений насчет репликаций - я не знаю, как там 3-4 часа БД грузят с полным простоем пользователей, но в ASA сервер автоматически фиксирует все происходящие DML операторы в логе, сразу распределяя их по публикакиям и области видимости информации по подпискам. Таким образом, когда сеансово запускается сервер репликации, ему не нужно трогать БД, чтобы считать данные, которые необходимо послать удаленной или консолидированной БД - ему достаточно просто прочитать лог-файлы (имеется ввиду не только лог-файл БД, но и те, которые были уведены в архив с обрезкой лога), собрать DML операторы в пакеты, сжать и закриптовать их и положить на мыло, ftp или файловую систему. При приеме пакетов их достаточно просто выполнить, как набор транзакций с DML операторами. Таким образом нагрузки на БД при работе репликаций минимальны, как я уже говорил, на ASA с репликацией считается вполне нормальным 500-700 удаленных серверов, за рубежом есть и по 10000.

P.S. Я думаю не нужно обьяснять, что периодически посылать и принимать только DML операторы гораздо меньше сьедает трафика, чем непрерывно тащить через удаленное соединение запросы и посылать обратно DML. Гораздо приятнее летать на локальной БД, не боясь за связь, чем поиметь кучу проблем с поддержкой канала, борьбой за время отклика центральной БД при большом кол-ве сессий и прочих неприятных вещей. НУ а насчет аргументов, зачем на удаленные узлы тащить все лишнее, отвечаю просто - а ничего лишнего и не тащиться. Есть понятие области видимости информации. На каждого подписчика отправляются только те изменения информации, которые входят в область видимости по условиям его подписки. Таким образом консолидированную БД можно считать как централизованные данные + данные для каждого узла. Насчет сложности проектирования и сопровождения репликации для ASA я уже говорил - сложностей нет, кодировать ничего не нужно, требования к правилам проектирования минимальны и сводятся к здравому смыслу и знанию самих основ механизма репликации, которые легко и доступно в виде примеров описаны в документации к серверу. Если кому то захочется почитать и ознакомиться, как же на самом деле автоматом без сопровождения работают оффлайн репликации, у нас в FAQ Sybase есть ссылка на полный BOL в интернете и 2 руссифицированных PDF, один из которых полностью посвящен SQLRemote репликации в ASA.

OTigerЗолотые слова, укажите пальчиком хоть на одну такую клиентскую часть? :) Я не имею ввиду програмульки с обрезанным функционалом по самое не могу под наладонники с ВЭБ интерфесом. Нормальное полнофункциональное приложение!
Да какие проблемы. Я когда клиентам демонстирую возможности наших программ, специально это делаю на стареньком ноутбуке, в который по блюту через GPRS сотика есть интернет через Мегафон. Показываю как это выглядит на плохих каналах связи через прямой доступ к нашему серверу, опубликованному в интернете, где кстати время отклика вполне в допустимых нормах. Далее показываю, как это выглядит через репликации. Далее показываю как это выглядит на хороших каналах связи, подрубая ноутбук к каналу клиента и работая напрямую с центральной БД. Далее отрубаю инет с ноутбука и показываю, что клиентская часть, не найдя центрального сервера автоматом подключилась на локальный и мы продолжаем работать уже локально. Врубаю обратно интернет и счастливо видим, как все наше локальное пакетами ушло на центральный сервер. Потом показываю, что репликация может быть многоуровневой, базы могут администрироваться и их схемы изменяться централизованно, и вопросов у клиентов по поводу, зачем оно нужно больше не возникает, наоборот возникают различные фантазии, где можно применить выделенку, где репликацию, а где лучше и то и другое сразу.

OTiger
Да ладно, Вас послушаешь, так SyBase прям уникальный продукт. Это делает любой приличный SQL Server.

Конечно уникальный, так как он единственный, кто не требует видимости серверов во время репликации и изначально позволяет любому, прочитав доку за полчаса, организовать репликацию на свою БД, пощелкав мышкой или пописав чуть чуть на WatcomSQL. Чтобы добиться подобной функциональности от Oracle или DB2 придется много чего поизучать и много чего ручками дописать.

OTigerА вот это интересно , эт вообще как, на дискетках чтоли? :)
Конечно, какая разница, кто передает пакеты - mail, ftp или пользователь файлами через файловую систему.

OTigerЗаскочите в ночное время на любой стационарный пункт ГИБДД с просьбой пробить номер-повеселитесь:)
Да любые госорганы - это вообще не показатель. С чего у них продукты и программы хорошими будут, когда всегда работают 2 подхода:
1. деньги на бюджет выделены, берем то, где больше откатов (привет Оракл)
2. деньги на бюджет не выделены, работаем на том, что умельцы придумали (привет клипперы, фоксы и кронусы)

OTiger
Читаю я Ваши размышления и все больше меня терзают смутные сомнения насчет реализации в таком виде крупной учетной системы.
Пишите Вы красиво насчет областей видимости, НО
берем элементарный пример. Создаем и проводим документ.
1. Создавать его можно долго, постоянно чтото меняя и т.д. Фактически Ваша технология этот один единственный документ отправит по инету раз 10...(в зависимости от частоты отправки-как настроите)
2. Этот документ содержит ссылки на кучу справочников и если Вы отправите один только документ, то на том конце будут сильно удивляться, а что же это пришло.
3. Когда мы проводим некий документ, у нас появляются проводки(их не мало), которые разлетаются на различные планы счетов. Как с ними? А если с той стороны решили документ распровести(поменять атрибуты документа или вообще поменять шаблон, по которому проводится документ?) и затем провести заново? А на нашей стороне все продолжают колбасить накладные и об изменениях какогото шаблона ни сном ни духом.
Еще раз подчеркиваю - во первых DML операций в репликации будет ровно столько же, сколько во время онлайн работы, так что такие доводы в плюсы ничего не ложат. Во вторых все остальные Ваши доводы - это в пользу бедных криворуких проектировщиков БД. Все вышеперечисленное штатно и легко решается, проблем ни на моих проектах, ни на проектах коллег, не замечено. Так что с моей точки зрения, проблемы, во всяком случае для ASA, надуманные.

OTigerТак что не все так гладко в Вашем королевстве, очень часто мгновенная актуализация данных весьма важна, в Вашем случае это не возможно. Значит уже накладываются определенные ограничения на функционал системы ы целом.
Никаких ограничений. Репликация раз в минуту или онлайн работа или одновременно онлайн работа с дублированием на локальный сервер через репликацию с возможностью автоматического переключения клиентских приложений на локальный сервер при падении канала связи. Все как и полагается предусмотренно штатно, все очень гладко и красиво :)

OTigerМы этих прочих неприятных вещей не имеем, за исключением поддержки канала-хотя далеко не везде это проблема. Но мы же с Вами говорим не о ларьках(врядли они потянут Вашу системку), а серьезному клиенту ничего не стоит провести серьезный инет. На обычном 10Мбит канале, где сидит под 10тыс юзверей я работаю с удаленной БД(через инет) даже не замечая этого. У многих ЕРП систем в локальной сети время отклика гораздо дольше.
Я вот был на конференции по ERP. Как раз тема онлайн каналов была очень актуальна, потому как популярные ERP не дружат с репликацией. Одна очень очень серьезная коммерческая контора, чтобы обвязать Аксаптой свои 3 завода, вложила в основные и дублирующие каналы связи бешенные деньги, удваивающие стоимость ERP и ее внедрения. Причем заводы эти в мегаполисах, не в Мухосрансках. Ну а насчет 10м канала и 10 тысяч юзверей - я тоже с дома спокойно с рабочими серверами работаю. И другие тысячи юзверей спокойно себе странички с инета грузят и занимаются своими делами. Вот если бы они все захотели к моей БД подключится и активено поработать, понабивать данные, аналитические отчетики попечатать - ни Ваш канал, ни Ваш сервер, ни Ваш РСУБД просто так не обеспечили бы нормального отклика системы, так что не нужно мне ежа с удавом сравнивать :)

OTigerВот, вот-опубликованному в интернете, а зачем? Да и ВЭБ интерфейс полагаю используется при этом?
С чего Вы взяли, что у меня используются веб-интерфейсы ? Слово опубликован не обязательно означает слово веб, а всего некий лишь открытый порт с использованием доменного имени или прямого ip. Ну а почему в интернете - так с базой могут работать куча географически удаленных точек, у кого каналы нормальные, без использования репликаций. Чего же им - в Москву свои каналы что ли всем тянуть ? Интернет милое дело, особенно когда РСУБД поддерживает криптографию по сертификатам и сжатие протокола.

OTigerНу а допустимое время отклика-понятие непостоянное у разных заказчиков. Каждому свое. Кому то допустимо, кому и не очень.
Допустимое время отклика системы - это время, которого готов ждать пользователь при открытии форм, получении отчетов и т.д. Например форму никто не будет ждать минуту, пока она откроется. А вот большой аналитический отчет пользователь готов подождать в крайнем случае и пару минут.

OTigerДля Вас, как работающего с ней легко, точно также легко это сделают программеры давно работающие на MSSQL, Oracle, DB2 на своих серверах.
Чтобы писать такие утверждения, Вам неплохо бы ознакомиться с возможностями репликаций этих серверов самому или пообщавшись с людьми, которые их давно используют. Однако, чтобы сделать правильные выводы, что легко и что сложно, неплохо бы и самому поюзать репликацию в какой либо РСУБД.

OTigerГде надуманные то? А по существу ответить? Пока лишь наблюдаю мягкий уход в сторону от вопроса с размазыванием каши по тарелке.:)
Ну зачем же мне Вам все подносить с азов на блюдечке с голубой каемочкой ? Изучите хотя бы азы работы механизмов репликации и Вы сами уже как проектировщик БД увидите ответы на все поставленные Вами вопросы. А писать одно и тоже из раза в раз и расжевывать мне надоело - дело в том, что если бы Вы задавали вопросы в целях изучения для практического применения - я бы с удовольствием помог и советами и кодом на том же форуме Sybase. А Вы задаете вопросы с целью спора, то есть изначально в моих ответах видите только продолжение спора, а не рациональные моменты, которые я уже выкладывал или же вообще считаете, что в практике это будет не так легко, как я рассказываю в теории. Поэтому если действительно интересует, какие еще есть подходы хранения и обработки географически распределенной информации, то можете сначала ознакомитьс с азами репликации ASA, как одной из самой легких в освоении на фоне других РСУБД:
http://sybase.sql.ru/asa9/SQL_Remote_Users_Guide_Rus.rar (PDF на русском)
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbsren9/dbsren9.htm (в онлайн на английском)
Далее, когда Вы уже не будете пропускать мимо ушей такие слова, как область видимости, фильтрация, конфликты версий и Вы сами поюзаете различные направления, скачав отсюда девелоперскую бесплатную версию ASA и поюзав репликацию, поймете как это выглядит и как это работает, вот тогда можно будет и поговорить и на практических примерах показать, какие есть возможность и как решать различные задачи и при желании Вы, уже пользуясь фактами сможете доказать, что на репликациях возможны сложно организуемые моменты для определенного круга задач. Так что все в Ваших руках - спорить нужно только имея на руках знания и факты, а не домыслы и слухи и цитируя Вас могу сказать, что пока, все, что Вы говорите про репликации - это чистая вода, не имеющая под собой конкретных фактов и опыта использования.

OTigerВот вот, раз в минуту. Менеджер когда работает с клиентом, документ может оформлять до получаса, постоянно меняя условия и скидки.
Итого имеем, что один и тот же документ Вы можете отправить порядка 30 раз.
Предопределяя Ваш ответ, что документ отправите только когда он до конца оформлен... А как же резервирование товара, услуги?
Элементарно реализуется, хоть тысячу раз дописывать будет документ, пойдет по репликации только последняя информация, никаких проблем, если умеешь проектировать БД и см. выше.

OTigerДык это потому что Аксапта еле живет даже в локальной сети, и не только Аксапта, а практически все крупные(известные) системы. О какой удаленке через интернет там вообще можно зарекаться?
Не вижу связи между тем, что "Акаспта еле живет" и резервными каналами связи. Суть в том, что 3 огромных производства, завязанные на центральные сервера, при любой остановке сети, остановяться сами и нанесут огромные убытки хозяевам. Отсюда и собственные резервные каналы связи. Хотя, с учетом того, что 3 завода абсолютно автономны, то распределение информации по серверам этих заводов и обьединение их в центре через репликации позволило бы не покупать резервные каналы связи и в любой момент переходить на автономный режим работы, когда к примеру в Москве исчез свет, что недавно было даже очень актуально.

OTigerДык там упирается все только в сервер. Это естественно. А вот с РСУБД все хорошо, куда она денется? Да и тольщина канала важна только у сервера, а подключайся к нему хоть по мобиле.
Я так понимаю, Вы свято уверены, что для любой РСУБД 10000 активных подключений это семечки, раз упираете только в толщину канала ? Вы в курсе, что требования к проектированию БД с таким кол-вом подключений будут в 10 раз жестче и критичнее, чем требования к проектированию БД с учетом репликаций с обслуживанием меньшего кол-ва пользователей ?

gardenmanВот такая вот задача (гипотетическая): Клиент желает снять деньги в отделении (А) банка причем в данный момент физически находится в другом отделении (Б) банка. Естественно в каждом отделении своя база данных. Более того - разные базы данных (исторически сложилось). В одном допустим Sybase ASA, а в другом DB2. Каким образом это сделать? Прокатит ли в этом случае репликация? Если базы разные - естественно нет. Даже если бы и одинаковые базы данных были - все равно не прокатило бы по соображениям безопасности. Репликация - она ведь всегда идет с задержной. Репликация - она ведь лишь свидетельствует свершившийся факт (взятый из транзакционного лога). Всегда существует вероятность мошенничества - типа клиент (группа преступников) может одновременно попытаться снять деньги в нескольких отделениях банка. Тогда в процессе репликации произойдет конфликт, и, когда со всем этим разберутся - то будет поздно. Как же быть?

Очень просто - использовать WebSphere MQ - менеждер очередей сообщений.

Работа происходит примерно так:
Приложение А посылает сообщение в очередь "Если есть у клиента бабки на счете, то зарезервировать нужную сумму". (и далее продолжает работу)
сообщение помещается в очередь, и в определенный момент времени, приложение в другом отделении (Б) заберет его оттуда и обработает. когда это произойдет - неизвестно. Приложение Б может запускаться когда угодно. Допустим раз в сутки, или несколько раз. После обработки принятого сообщения приложение Б посылает ответ - дескать всё в порядке (или не в порядке, нужное подчеркнуть), которое также помещается в очередь, откуда будет забрано приложением А, тогда, когда у него найдется на это время, т.е. асинхронно. Получив положительный ответ приложение А сообщает что бабки клиенту могут быть выданы. Клиенту выдаются бабки, а в отделение Б посылается сообщение что бабки выданы.
Таким образом распределенная транзакция превращается в бизнес-транзакцию.
Выгоды от такого подхода очевидны.
1) Через сеть проходят только нужные сообщения (снижается трафик, растет производительность)
2) Конфликты - исключены (надежность)
3) можно связать всё со всем (какую угодно базу с какой угодно, или даже приложение с приложением).
4) Если сообщение в XML - то .... короче гибкость офигительная...

Короче - все дружно забили на Sybase ASA и изучаем WebSphere MQ...

Что то я не очень понял смысла. Если между банками неустойчивая связь или она временно отсутствует, то каким образом MQ поможет клиенту снять деньги со своего счета в другом отделении банка, если ему ответят - ждите. связи нет, мы пока не знаем, есть ли на Вашем счету деньги ?

Если же связь есть, то есть такие вещи, как RemoteServers и WebServices, которые помогут и зарезервировать деньги и отчитаться хоть через прямой RPC с поддержкой транзакций между обеими базами, что хоть через SOAP с XML. ASA и DB2 спокойно поддерживают RPC и веб-сервисы с XML и SOAP, так что связать их работу между банками напрямую насколько я понимаю, трудностей не представляет, причем в данном случае репликация, назначение которой совершенно другое и под такие случаи не подходит, я честно говоря не понимаю.

gardenmanХорошо, что наконец-то согласились что репликация катит не под все случаи. Порогресс однако.
А я вроде нигде и не говорил, что репликация панацея от всех бед. Помнится я говорил, что репликация во многих случаях выглядит гораздо более надежной и удобной, чем организация всех удаленных клиентов через онлайн. И круг задач, критичных к реалтайм гораздо меньше, чем тех, где использование репликации вполне достаточно для организации обмена данными между удаленными узлами.

gardenmanRemoteServices и WebServices подразумевают полный online.
А MQ - подразумевает эпизодичекую (можно сказать что почту) связь на основе асинхронных сообщений. т.е. MQ может полностью заменить offline репликацию, которой так кичится Syabse ASA. Кстати, DB2 может реплицироваться и через MQ тоже. Это так, к слову.
Ну по первых поставленная Вами задача изначально решается только средствами онлайна - ну не будет клиент ждать в отделении банка, пока "эпизодическая" связь таки доставит запрос и ответ. Во вторых - извините, ну может MQ делать тоже, что и SQLRemote, тогда в чем ее преимущества ? В ASA все - репликации, работа с удаленными серверами, построение веб-сервисов, события и прочее - это часть сервера и операторы на диалекте WatcomSQL, то есть единый язык, единая работа сервера без сторонних модулей и утилит. Из плюсов - легкость изучения, так как все лежит в единых концепциях, большая функциональность и скорость в результате интеграции в ядро сервера. Это и параллейная фиксация в логе транзакций для подписчиков и определение области видимости информации, фильтров, это триггеры разрешения конфликтов. Плюс полное управление из бизнес-логики БД, с тех же хранимых процедур, что позволяет легко вывести уровень управления удаленными серверами и репликацией прямо в свое приложение и сделать свою полноценную админку для обычных пользователей, что правильно ложится в концепции нулевого администрирования. MQ я так понял штука отдельная от сервера DB2 или я ошибаюсь и она является частью DB2 ?