Есть необходимость создать БД учета договоров страховой компании
1. 30 филиалов (120 конкуретных соединений одновременно 40% пишут-60% читают).
2. В главной табличке порядка 120 К записей в год
3. В подчиненных к главной таблице порядка 50 записей на всех на 1 запись в главной
4. Около 15 справочников, максимальный 20К записей
5. Необходима работа он-лайн без репликаций скорость минимальная 256/256К максимальная 512/512
6/ 30-40 несложных отчетов (1-2 селекта)
7. Возможность аттачмента фотографий и скан-копий документов (можно в ФС по ссылке, необязательно BLOB)

Что выбрать
1. Прикрутить к 1С 8.1 Бухгалтерия модуль договора и работать через RDP
2. Создать в Access 2003(2007) adp-проект к MS SQL Server 2005 Express или Standart и рабоать в RDP
+импорт проводок в 1С 8.1 ночью
3. Oracle XE+AppServer+web +импорт проводок в 1С 8.1
4.???
Спасибо

gardenman wilandЕсть необходимость создать БД учета договоров страховой компании
1. 30 филиалов (120 конкуретных соединений одновременно 40% пишут-60% читают).
2. В главной табличке порядка 120 К записей в год
3. В подчиненных к главной таблице порядка 50 записей на всех на 1 запись в главной
4. Около 15 справочников, максимальный 20К записей
5. Необходима работа он-лайн без репликаций скорость минимальная 256/256К максимальная 512/512
6/ 30-40 несложных отчетов (1-2 селекта)
7. Возможность аттачмента фотографий и скан-копий документов (можно в ФС по ссылке, необязательно BLOB)

Что выбрать
1. Прикрутить к 1С 8.1 Бухгалтерия модуль договора и работать через RDP
2. Создать в Access 2003(2007) adp-проект к MS SQL Server 2005 Express или Standart и рабоать в RDP
+импорт проводок в 1С 8.1 ночью
3. Oracle XE+AppServer+web +импорт проводок в 1С 8.1
4.???
Спасибо

У меня вопрос. Вы действительно решили работать On Line?
И без этого никак? Насколько это существенно?
Дело в том что можно работать и без рекпликации и оffline а просто использовать ПО именуемое Data Hub - для поиска и объединения дубликатов. Все же страховой компании не требуется работа в режиме реального времени. Это же не процессинговый центр.

Кстати, если вы надеетесь прикрутить страхование к 1С,... то ха-ха-ха...
Страхование не заканчивается регистрацией договора. Потому как учет страховых случаев, перестрахование, отчетность, расчет ЗП агентов - это очень-очень много. Софт должен быть специализированным.

В принципе он-лайн не критичен, просто имея единую базу, не нужно обновлять ПО на местах, в случае выхода новых исправлений и доработок.
Желателен веб, вы правы насчет 1С. Но где взять готовое решение?

miksoft wilandЧто выбрать
1. Прикрутить к 1С 8.1 Бухгалтерия модуль договора и работать через RDP
2. Создать в Access 2003(2007) adp-проект к MS SQL Server 2005 Express или Standart и рабоать в RDP
+импорт проводок в 1С 8.1 ночью
3. Oracle XE+AppServer+web +импорт проводок в 1С 8.1
4.???
СпасибоА 1С тут каким боком? он уже используется? если да, то имхо, первый вариант, чтобы зоопарк не разводить и огородов не городить.
Да типовая бухгалтерия

softwarer wilandВ принципе он-лайн не критичен, просто имея единую базу, не нужно обновлять ПО на местах, в случае выхода новых исправлений и доработок.
Простите, но это соображение действует только для компаний, не имеющих в штате ни одного мало-мальски грамотного айтишника. Написание и внедрение такой софтины, даже если она действительно уложится в задекларированные скромные объемы - стоит минимум тысячи баксов, скорее десятки тысяч. Десять лет назад за автоматизацию одного из направлений деятельности одна из страховых компаний заплатила нам порядка двухсот тысяч. Настроить "обновление ПО на местах" стоит несколько десятков баксов, делать это соображение критерием выбора просто смешно.

Представим филиал в крупном поселке (их например скоро будет около 100 штук). А ну-ка попробуем сделать репликации. 100% будут конфиликты реплик и т.д. Плюс изменение клиента предполагает миниму выкладка нового релиза на фтп (мэйл) подробная инструкуия по обновлению без единого айти персонала на месте. Плюс обзвон центрального ИТ отдела всех филиалов в случае проблем. Единая база при хорошем канале -это грамотное решение. Размазка по всей стране это прошлый век.

Свежие новостиСовместными заслугами одного из крупнейших интеграторов и собственного отдела айти одной из крупнейших страховых компаний был успешно провален проект создания основной информационной системы.

А какой компании идет речь, и какую системы внедряли?

softwarer wilandПлюс изменение клиента предполагает миниму выкладка нового релиза на фтп (мэйл) подробная инструкуия по обновлению без единого айти персонала на месте.
Ну Вы даете.

Если мы говорим о клиент-серверном решении (клиентская часть, например Delphi, C#) и некой СУБД Oracle, SQL Server. Таким образом данные меняютя на уровне СУБД и только. При появлении новой формы, кнопки, контрола и прочее, необходимо ФИЗИЧЕСКИ доставить обновление на филиала. Вариант №1 -выслать файл(ы) обновления и пользователь по инструкции обновит. Вариант № 2-самостоятельное обновление при вхождении юзером в программу проверятся наличие свежей версии, если она есть, то происхоид обновление.

softwarer wilandВариант №1
Жуть.

wilandВариант № 2
Лучше, но неоптимально. Если во всех филиалах, кроме одного, по паре пользователей - можно использовать.

А почему бы не сделать нормально?
Нормально -это как?