Рукводство поставило задачу по разработке (не коробочная версия) такой системы. То есть будем нанимать комнаду разработчиков.
Мини ТЗ
1.Ежедневный импорт платежей из банка (40 филиалов).
2.Отнесение платежей по разным видам учета (10 пользователей).
3.Импорт (или репликация из филиальных баз) счетов на оплату, платежи осуществляют пользователи в центральной базе за филилалы.
4.Акцептирование счетов разными службами.
5.Контроль расхода денег, в соответствии с бюджетом.
6. В перспективе экспорт платежей из базы в банк.
Средний ростцентральной базы, по прикинутой мной структуре таблиц суммарно около 8000 записей в день.

1.Что посоветуете в качестве СУБД в центральной базе и почему, если не влом писать?
2.Что посоветуете в качестве СУБД для филиалов?
3.На каком средстве разработки писать клиента, исходя из выбранной СУБД и из ТЗ?
4.Каков порядок бюджета на все это дело, без учета железа?

Спасибо.

Забыл уточнить у нас крутится 1С 80, под MSSQL2000, соответственно на стоит win2k3 server, можно конечно купить еще один сервак специально под линух это в центральной базе, а на филиалах тогда что делать, там еще один сервер не купишь 1С пол линух не работает, только под win.

Yo.!! it-templarЗабыл уточнить у нас крутится 1С 80, под MSSQL2000, соответственно на стоит win2k3 server, можно конечно купить еще один сервак специально под линух это в центральной базе, а на филиалах тогда что делать, там еще один сервер не купишь 1С пол линух не работает, только под win.

ну тогда дешеле всего в той же mssql создать базу для вашей задачи, сверху прикрутить soap для передачи данных и не выеживатся с другими субд. если конечно 1С у филиалов не на dbf.

1С под mssql

у нас процессорная лизенция на всех филиалах мы покупали отдельно от 1С

Александр Гoлдун it-templar
1.Ежедневный импорт платежей из банка (40 филиалов).
...
3.Импорт (или репликация из филиальных баз) счетов на оплату, платежи осуществляют пользователи в центральной базе за филилалы.
...
1.Что посоветуете в качестве СУБД в центральной базе и почему, если не влом писать?
2.Что посоветуете в качестве СУБД для филиалов?

Sybase SQL Anywhere.
Наиболее весомые причины такого выбора для этой задачи на мой взгляд:
1. Развитые средства репликации, включая off-line репликацию по любым каналам связи (включая курьера с дискеткой на верблюде - не шутка)
2. Богатые функциональные возможности для разработчика, использующего сервер, что может заметно удешевить разработку.
3. Низкие затраты на обслуживание - актуально для малочисленных удаленных филиалов, не имеющих возможности держать в штате квалифицированных админов.
4. Защита информации - шифрование как файлов БД, так и сетевого траффика с использованием криптостойких алогитмов (файл БД можно шифровать по AES)
5. Встроенный Web-сервер, поддержка XML, SOAP web-сервисов, что тоже может потребоваться, например для централизованной раздачи информации.

Можно много чего еще написать, но времени мало, лучше давай наводящие вопросы, если интересно. Такой выбор я предпочел бы как для филиальных баз, так и для центральной. SQL Anywhere прекасно справляется и с достаточно большими базами и нагрузками. Имеет весьма хороший оптимизатор, прекрасно использует возможности многопроцессорных машин и т.д.


it-templar
3.На каком средстве разработки писать клиента, исходя из выбранной СУБД и из ТЗ?

Непринципиально. На чем больше нравится.
--

Портал русскоязычной группы пользователей Sybase

ASA не будет страдать от майкрософта, или лучше все вынести на отдельный сервер?

Александр Гoлдун Yo.!!
Александр Гoлдун Это дешевле (может быть) по начальным затратам на коробки (если во всех филиалах действительно уже есть MSSQL). Если считать еще и стоимость разработки и сопровождения, то разница может оказаться в другую сторону, причем существенно.
сумневаюсь я что зоопарк из разных субд куда то перевесит,
Какой зоопарк? Кесарю - кесарево. Т.е. одинэсу - MSSQL. Наличие 1с+MSSQL не обязательно подразумевает наличия квалифицированных разработчиков, близко знакомых с MSSQL.
Но не будучи фанатом, я рассмотрел бы альтернативу предложенному мной варианту - реализация всего этого вообще в 1с8. Это при условии что имеется своя команда разработчиков 1с. Ну и грамотный руководитель проекта, системный архитектор

Дело, в том, что эта система критическа важна, по ней проходит будет в среднем несколько млн. в долларовом эквиваленте в день. А 1с пока еще находится в стадии внедрения и еще много багов как в бухгалтерии, так и в зарплате, и если еще туда и планирование платежей прикрутить, то все может стать вообще. Поясню, допустим у бухгалтер обнаружил баг в бухгалтерии, мои действия- захожу к ним в терминале, если баг не сложный фиксю его в центре и выпускаю на все филилалы обновления, если же сложный, то выгружаю их базу скачиваю в центр и уже в отладчике решаю проблему, в отладчике в терминале даже со сносным каналом, кои у нас везде стоят 128-256к не поработаешь. Соответственно, пока я устраняю их баг предприятие не работает ждет меня, в среднем 2-3 часа простоя. Это наследство от внедренцев-студентов 1с8 были до меня. Понятное дело, что для столь важной критической информации в 1с это вводить нельзя. Очень боюсь.

2Александр
Конечно я так не думаю.
Так вы сравниваете монстра в плане функционала и количества объектов, которого можно даже назвать "ERP c натяжкой",я имею ввиду УПП и систему с полтора десятками таблиц, несколькими десятками ХП, двумя десятками форм и десятком отчетов. Система по-моему мнению должна быть очень проста и супернадежна. а также иметь хорошо отлаживаемый и лекго читаемый код, в случае если я уволюсь или заболею

Yo.!! it-templar Система по-моему мнению должна быть очень проста и супернадежна.

на решениях MS это импосибле
имхо одно требование антивируса на сервере субд должно наводить на рзмышления ...

Я тут на форуме читал про оракл ХЕ, там вроде как еще и какой-то вэб интерфейс идет с поставкой, в котором даже можно и формы рисовать, или я ошибаюсь?

не знаю, можно спросить у Yo, судя по его постам он большой поклонник Oracle и должен вероятно знать.