Всем привет!!!
Специалисты помогите определиться с правильностью мысли.

Коротко задача:
Знакомый попросил сделать несложную программку для учета операций. Он главный менеджер, имеет около 20 подменеджеров, они в разных городах. Он продает изделия, для учета продажи, хочет вводить продажи в программку. Также должны вводить в программку свои продажи его менеджеры (представители в других городах). Главный менеджер видит все свои операции и естественно всех своих менеджеров. Также задает им при необходимости некие числовые параметры. У всех есть своя база. Программа главного Менеджера при наличии соединения (tcp/ip) с подменеджером копирует себе его операции и если нужно вставляет некие числовые параметры.

Думаю сделать в связке c# + SQLite
почему SQLite? - не требует настройки при установке на клиента, не нужно поднимать сервисы как в майскул и т.д. Скорость работы. Простота резервирования.

Вот еще схемка для наглядности:



Возможно увеличение подменеджеров до 100.

Хотелось бы услышать комментарии специалистов, возможные проблемы, подводные камни, ограничения SQLite и т.д.
Сильно не пинайте, опыта в такого рода проектах особо нет. Делал нечто похожее, но проще c# + майскул

Спасибо!

упустил то, что эта субд не поддерживает сетевого доступа. тогда единственная альтернатива MySql

хотя как вариант, можно держать буферную базу (второй файл) для обмена инфой и гонять его туда/сюда....
не знаю насколько это черезжопный метод))))

МСУВам сюда http://www.sql.ru/forum/actualtopics.aspx?bid=10

ну сравнивание субд не есть основной вопрос этого топика....

окей, тогда так, субд уже выбрал - SQLite, так как принципиально простота разворачивания и ненужность администрирования.

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

МСУПопробуйте рассмотреть такую архитектуру:
1. Хостинг (платный или свой)
2. Единый ASP.NET портал для всех участников
3. Единая центральная СУБД при сайте
4. Никакого геморроя с синхронизацией, обновлением софта и схемы данных
5. Для работы в оффлайне - толстый клиент (WinForms или WPF) + родной Compact SQL. Обновление софта - ClickOnce через инет.
6. Синхронизация данных с оффлайновых клиентов: аттачим файл БД на специальной страничке портала. На сервере производится валидация и разбор данных, импорт в центральную БД.

большое спасибо, вариант очень интересный.


Единый ASP.NET портал для всех участников - я там понимаю ASP.NET будет держать свою базу Microsoft_SQL_Server?

аттачим файл БД на специальной страничке портала. На сервере производится валидация и разбор данных, импорт в центральную БД - это все можно реализовать автоматически? Без вмешательства пользователя?

А можно такую же схемку, только вместо Microsoft_SQL_Server юзать MySQL? Так как опыта в Microsoft_SQL_Server и ASP нет, это не подходит.

И не очень понятна роль ASP в этой схеме. Пользователю на вебстранице совершенно нечего делать.

Вы чего курите? :) Это же веб-морда для бизнеса, юзеры будут трудиться в ней и только в ней. Не считая оффлайна.
---
ничего)))) просто как говорил им нужны винформс клиенты и не больше, а майскул крутящийся на сервере рассматриваю как центральную базу, чтоб действительно не городить огород с синхронизациями....


по всем остальным пунктам понятно. спасиб.

Алексей КМожет лучше наладить нормальный канал связи, всех подсоединить к одной БД и не париться с репликацией локальных БД? Все эти локальные хранилища и псевдо-оффлайн работа - сказки для бедных.

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

вот, вроде хорошее решение....

[quot МСУ]SputnickИдеальный вариант для ASP.NET решения. Толстое приложение - зло. )

это почему ))))?

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

ну вот пропал инет, авария, или не заплатили, или еще чего нибудь.... а шефу срочно надо отчет по вчерашним продажам.... тут и все, тю-тю ))))

[quot МСУ]Алексей КВ случае с толстым приложением тоже самое, база-то недоступна, если сетка накрылась. Веб-приложение отлично работает и в вебе и в интранете.
.

у меня немного проще - подменеджер сидит у себя в офисе и у него один комп, на котором приложение + рядом с экзешником лежим локальная файловая БД, специально для случаев не доступности центральной. То-есть сети предприятия нет. Есть сеть манагеров, у каждого один комп и одно приложение....)

а вот еще вопрос, сколько хотя бы примерно может стоить такая работа?

централизованная MySQL (на хостере), вин приложение, которое работает с этой удаленной БД. Логика в самых общих чертах как рисовал выше - есть главный менеджер - вводит свои операции и видит операции всех подменеджеров. Подменеджеры вводят свои операции и видят себя.