Уважаемые, хочу посоветоваться с гуру :)

На данный момент есть некая корпоративная выносная система, которая посредством транспортного модуля синхронизируется с основной. СУБД PostgreSQL 8.0, GUI на C# (доступ через ODBC), транспортный модуль - Java (доступ JDBC). Разработчики-аутсорсеры выбрали очень красивый вариант работы - на хранимых процедурах (т.е. сам GUI знает минимум о данных, только как их отображать и что дернуть для изменения) и представлениях-view (т.е. еще в GUI и запросов как таковых нет). Этот же подход позволяет вынос интегрировать с самыми разными системами т.к. вся логика управления данными доступна по ODBC подключению.

Однако есть большой-большой минус - все это до ужаса тормозно. Из главной базы в выносные ежедневно обновляется 30-50 мб данных (это в текстовом представлении), да плюс со стороны выноса накапливается некоторое количество данных (они постоянно в обмене и изменениях). В итоге за месяц база выноса прибавляет 10-50 мб, но те данные, что в ней есть, постоянно обновляются.

Еще один минус - нестабильность. Выносов в среднем от 500 до 800, абсолютно все работают под Windows (знаю, что единичные базы перенесены под *nix и там проблем абсолютно никаких).

На данный момент есть факт перехода на новую "материнскую" ИС и всвязи с этим есть возможность проимпрувить вынос. Вопрос главный - выбор СУБД. Т.к. выносов много и все они отдельные юридические лица, варианты с платными СУБД отпадают (если конечно лицензирование не позволит купить лицензию для всех партнеров). PostgreSQL мне лично нравится очень, но он достаточно сложен в администрировании (для совсем не администраторов, коих большинство) и падуч, хотелось бы что-то полегче, возможно (и желательно) одним файлом, но с хранимым функционалом (т.к. архитектуру очень хочу сохранить).

Что вы можете посоветовать?

Хорошо вы заметили, с однопользовательской и сетевой версией. Насколько я знаком с Firebird, базу одним файлом дополнительным сервером можно сделать сетевой, верно? С SQLite я не знаком вообще, но чувствую придется посмотреть что это такое.

Утилиты-упрощалки администрирвоания - уже написаны. Автообновление структуры, заполнение данных при установке - тоже. Это было бы решением, если бы не падучесть постгресса. Минимум раз-два в месяц имею ситуацию, когда у кого-то вырубился свет и база умерла. Приходится ставить начисто, но в результате возникает буфер незаполненных данных (начали вести, но не успели), которые достаточно проблемно закрыть. А делать репликации в чистую базу не позволяют корпоративные правила :(

А по поводу легких путей - мы их не ищем :) Миграция ИС у нас будет с SAP R/3 4.6 на SAP ERP 2005, знающие люди поймут

Самые частые причины - моргнул свет, комп задумался и девочка-оператор его резетнула. База после этого - местами либо уходит в зависы, либо без большого куска данных. У 8.3 с этим получше?

Mr MarmeladAT/F0x,

Коллега - Ваша ключевая фраза вот тут " абсолютно все работают под Windows ". Как показала практика в Этой платформе всегда предпочтительнее MS SQL Server тем более в SAP R\3 связке...
Неее, связка - это отдельная песня. Она написана на SAP BC через XML и поэтому абсолютно универсальна. Отчасти - этот интерфейс реальное произведение. Если бы не некоторые личности :D

Senya_LЭто все следствие использования "выносных" БД. По сути повторяете путь файл-серверных СУБД, когда по сути вся БД "закачивалась" на локальный комп, а потом делался posting данных - по сути та же синхронизация, о которой Вы упоминаете.
Постинг - это проще. У нас есть целая иерархия документов и статусов к ним, все они ходят в реальном времени. Причем инициируются они с совершенно разных сторон.

Senya_LНе вижу никакой красоты. Красиво, это когда ново, а иначе это нормальная рабочая практика. У нас все обращения к БД идут через ХП и мне ни приходило в голову восхититься красотой такого построения.
Красиво оно в том, что есть порядка 100-200 связок "выноса" и ИС партнеров. И они реализованы через ХП, что сразу накладывает правила всей нашей ИС, еще до синхронизации.