Прекрасно понимаю, что для подобных тем имеется свой раздел на форуме, однако мне бы хотелось рассмотреть именно возможность использования ASA в качестве СУБД.

Итак, исходные данные. В ближайший месяц начинаем автоматизацию крупного диспансера (поликлиника+стационар) уровня региона, т.е. довольно крупный. Т.к. я не знаю пределов возможностей ASA, посему и хотелось бы услышать мнение гуру на сей счет.
Предполагаемая нагрузка:
- регистратура: от 5 до 10 человек одновременно; основная работа - внесение новых записей о пациентах, распечатка внесенных данных;
- поликлиника: от 15 до 30 человек, внесение данных об осмотрах пациентов, распечатка внесенных данных;
- приемный покой: от 3 до 6 человек, внесение данных историй болезни, распечатка внесенных данных;
- отделения: (самое сложное в оценке) пусть от 50 до 100 человек, ведение и/б, распечатка документов;
- мед. статистика: от 5 до 10 человек, проверка внесенных данных, распечатка недостающих документов, раз в день/неделю/месяц/год - формирование различных отчетов;
Ну и еще порядка 20 рабочих мест других направлений деятельности, не слишком сильно влияющих на приведенную выше картину.

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

ASCRUSASA9+Delphi+DevExpress+FastReport и славная программа получится.
В данный момент используется практически такая же связка, только СУБД другая, и для части отчетов используется Excel.
ASCRUSЕсть только небольшой список "НО", но никак не касающихся самой ASA:
1. Согласятся ли в медицинском учреждении покупать лицензии ASA (ну или как вариант - согласятся ли постепенно подкупать лицензии, "постепенно сдавая" по местам с опытно-промышленной эксплуатации на рабочую версию ...).
2. Есть ли внятная постановка и грамотный проектировщик БД, который может реализовать схему документооборота, которая бы позволяла легко регистрировать в системе по различным отделениям новые типы документов, изначально проектироваться с учетом возможности использования по удаленным узлам репликации и т.д.
3. Сроки и финансы. Если проект разбит на этапы, где каждый этап представляет из себя серию модулей, достаточно автономных до степени возможности их запуска у заказчика и после каждого успешного приема, начала работы, заказчик платит обозначеные за этап деньги, то есть хороший шанс имея на руках материальную заинтересованность, определенные временные интервалы и тестирование/реальную работу заказчика на уже готовых модулях, взять за основу кое что из экстремального программирования и удачно завершить проект.

P.S. Если все таки решитесь взять ASA и все 3 пункта одолеете, то если будет нужно, могу поделится собственными наработками для ASA - системы управления доступом пользователей, организация хранения информации по узлам, фильтрация по схемам SQL, генерации SQL-скриптов по шаблонам (MacroSQL, но для особо упорных), скоро - CSV под ASA, ну и по мелочам. В принципе я хотел доделать CSV и открыть все это в public, но времени сделать инет-клиента пока все нет :(

В любом случае - удачи :)

По пунктам:
1. Согласятся. Ибо, когда встал вопрос о выборе СУБД, то было получено принципиальное согласие на покупку лицензии на Oracle (но у меня самого к нему душа не лежит :)).
2. Схема есть - уже запущен и вовсю работает проект автоматизации крупного онкологического стационара (в текущем проекте используется MySQL, но есть желание от него отходить). Правда, подлежит доработке с учетом общей направленности нового объекта и дополнительных требований, но, думаю, особых проблем не возникнет.
3. Именно так все и есть. Текущий процесс в чем-то напоминает XP, правда, с доработками, удалением части не совсем, имхо, реальных элементов.

По поводу P.S. :) Было бы очень интересно на все это посмотреть :)

ASCRUSСам бы я это естественно сделал на PowerBuilder, хотя бы потому, что у меня сильно много завязанного повторно-наследуемого кода ASA+PB есть. Но при желании сделать аналог на Delphi при условии использования DevExpress не вижу сложности, просто дополнительные временные затраты на разработку и тестирование компонент, эмулирующих все то, что уже есть у меня в PB. Правда я рекомендую Jager при выборе Delphi очень серьезно подойти к выбору компонент доступа к ASA, это будет одно из критичных мест при начале проектирования клиентского приложения.
Аналогично - есть много наработок (своеобразное ядро), которые можно (и нужно) использовать во всех приложениях БД. Используя их, в некоторых случаях получалось 5-тикратное ускорение процесса разработки.
А вот с компонентами - это вопрос. Учитывая, что ядро (в данный момент) работает на "чистых" SQL-запросах без использования таблиц, то нужен по сути только TxxxQuery :) Ну и что-то типа StoredProc.

White OwlЕсли вопрос перефразировать: будет ли жить ASA под такой нагрузкой? Ответ: да, без проблем.
Плюс, при географически разнесеных отделениях и плохой связи между ними, можно будет поставить несколько баз с периодической синхронизацей данных.
В том то и дело, что географически разнесенных отделений нет, между зданиями лежит оптика.

Спасибо за предложения :) Буду смотреть, сравнивать, тестировать, и в итоге - выбирать :)

ASCRUSЕсли все таки решитесь взять ASA и все 3 пункта одолеете, то если будет нужно, могу поделится собственными наработками для ASA - системы управления доступом пользователей, организация хранения информации по узлам, фильтрация по схемам SQL, генерации SQL-скриптов по шаблонам (MacroSQL, но для особо упорных), скоро - CSV под ASA, ну и по мелочам. В принципе я хотел доделать CSV и открыть все это в public, но времени сделать инет-клиента пока все нет :(

В любом случае - удачи :)

Можно что-либо из перечисленного ручками пощупать? :)

А может не стоит так уж сильно рекламировать свои разработки? Обозначили их наличие, указали сайт, и может хватит? Тема то не для этого предназначалась...

Спасибо, буду ждать с нетерпением.

P.S. Можно на ты, если возможно :).