Присоединяюсь к ASCRUS.
Недорого + репликация, что позволит не работать напрямую по модемным линиям, а сливать АВТОМАТИЧЕСКИ инфу через определенные промежутки времени (причем во всех узлах у вас будет одна и та же информация. это же здорово!)
Насчет архивации... в чем ее смысл? т.е. если вы захотите информацию 5-летней давности, вы пойдете за архивом на ленте?... а потом еще другой что-нить попросит и т.д.? Я знаю, что леч. учереждение вообще ничего не покупает, но вы им объясните, что хотя бы на оборудовании экономить не стоит...

И еще, если что-либо не заработает с самого начала, не стоит идти на поводу традиционного лозунга типа "Гамно, не фига не работает, тормозит и т.д.". Поверьте, все работает.

авторОпять же проблема с репликацией БД.....

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

авторДа чего с чем реплицировать то надо?
Однажды мне пришлось искать одну свою знакомую по нескольким больницам, мотаясь на автомобиле в пробках (слава богу все обошлось, оказалось она пошла на презентацию, никого не предупредив). Я проклял все на свете, в том числе и министра по здравохранению, по той простой причине, что не было "простой" комп. системы, благодаря которой можно было бы нехитрым запросом узнать, поступал ли человек в ЛЮБУЮ клинику в течение дня. Теперь вам понятна глобальная идея репликации?

В этом плане у сабеса (sybase) доступных конкурентов нет!

авторЕсли бы это была техническая проблема ...
а какая? т.е. написать систему на оракле в одной больнице, на всяких "огненных птицах" в другой, в третьей будет аксесс - и о чудо! - вот и еще одна сфера деятельности на несколько лет: как это все хозяйство объединить.
в принципе вы правы, технических проблем не бывает - бывают только организационные.

вопрос был другой.
человек искал субд для разработки системы для больницы. Если он изначально начнет разрабатывать с учетом репликации, то перспектива будет очень радужной.
Я понимаю, когда специфика работ отличается существенно, но больница...

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

авторГде в вопросе было множество связанных больниц, или Минздрав в целом?
Ответ:
автор топикаРабота заключается в интенсивной вставке и обновлении записей в базу из примерно двух сотен таблиц. Кол-во записей в интенсивно обновляемых таблицах(их около десяти) - от 0 ( в начале работы) до примерно 1 миллиона в конце года, полей примерно по 70-8- в каждой. Потом, по окончании годового отчетного периода, эти данные предполагается архивировать в другую базу с идентичной структурой.
Что посоветуете?

авторНо по твоей логике даже начав писать калькулятор никак не обойтись однопроцессорной тачкой, ибо вдруг понадобится умножить 2*2 в мировом масштабе.
Сразу видно, вы ни разу не писали систему, участвующей в репликации. Мне пришлось перебрать несколько СУБД, прежде чем нашел что-то реально работающее. Аппаратные требования для ASA более чем скромные. А настройка крайне проста.

авторИМХО
тогда все в порядке...
З.Ы. про калькулятор - как-то слабенько.

Заказчик может и не знать, что ему захочется видеть все данные из всех точек. Завтра он изъявил желание. Что будете делать? объяснять, что он хочет нереального?...

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

авторсоветую все таки составлять ТЗ чтоб потом не заниматся всякой порнухой типа удолетворения клиентов ;)
Оффтоп, ты должен поменять свое мышление. Если твой клиент останется недовольным, то пострадаешь только ты. Об этом уже говорилось 100 раз умными людьми. Твоя супер-программа без сопровождения/развития кроме тебя никому не нужна. Оракл, Сайбейз, Микрософт - это все, извините, молотки, рубанки, при помощи которых все сколачиваете нечто. Если изначально построено Г, вы его перепИшете, или ваше творение будет спустя некоторое время вытеснено более качественным развивающимся продуктом.

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

авторЗадача понятна. Более того, могу усугубить, что желательно было бы иметь информацию о наличии свободных коек, запасах критичных лекарств и т.д. Но при чем здесь репликация? И технические проблемы. Это чисто организационная задача.

А разве плохо из любой точки знать текущее состояние в любом пункте с разумной, скажем 3-4 минуты задержкой? Пусть про койки и лекарства делает запросы та группа людей, которой это необходимо.
А при чем здесь репликация? потому что в огненных птицах универсального решения нет, и вам придется писать свой велосипед. Оракл - с месяц назад мы обсуждали вопросы, никто толком не сказал как это все делается, приводились диаграммки, схемки с человечками и т.д. Вот тут у вас и будет техническая проблема, прикрытая неудачно организованной задачей.

SEF, сходи в ветку Sybase, поищи слово репликация, посмотри факи, посмотри как просто настраивается этот продукт, в конце концов скачай developer версию сервера, поэкспериментируй на 2-3 машинах в локальной сетке и использованием ftp-сервера. Как говорилось в известном мультфильме: лучше день потерять, потом за полчаса долететь.
Сделаете большую ошибку, если не выберете ASA.
Меня прям надо в отдел продаж