@Umka_

Всем привет. Возможно вопрос не в тему, тогда прошу прощения и переадресуйте меня туда, где можно обсудить мою проблему.
Итак суть проблемы:
Есть маленькая программа для компании, которая делает и продает двери. Написана еще на VS2005, БД access. Реализовано создание и печать договоров и всяких отчетов для передачи в цех по изготовлению дверей, и так еще немного функций по-мелочи. Вообщем всех все устраивало. Но потом бизнесс начал расти и процветать . В итоге открылись филиалы в других городах, куда так же поставили мою программу (пока 4 филиала). Когда открывали первый филиал мне уже стало понятно, что скоро встанет вопрос о том, чтобы сделать единую БД для всех филиалов. И вот это дошло и до Заказчика. Теперь передо мной стоит вопрос, КАК ЭТО СДЕЛАТЬ?
Одновременно работать с БД будут пока что 4-5 человек. Потом возможно больше, но думаю, что до 15 вряд ли дойдет.
Я вижу такие варианты:
1. Перенести БД на бесплатную СУБД типа MYSQL и переписать доступ к БД. Из других городов подключение будет по VPN. В офис надо будет покупать сервак. Есть проблема с обновлением ПО, т.к. во все филиалы придется ехать, а одновременно это не сделаешь.
2. Выбросить старую прогу и написать нормальное веб-приложение. СУБД тоже придется заменить. Из плохого - юзерам придется переучиваться и привыкать к новому интерфейсу. Но зато проблем с обновлением не будет. Сервак либо купить, либо выложить все на хостинг. Но хостинг для меня пока что нечто неизвестное и что и как я пока не знаю.
Извините, что так длинно получилось.

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

0

@ArtOfLife

Переписывать под вэб, как мне кажется, - не вариант. Это все - время на написание + отладка + тестирование + учет требований заказчика, и постоянный саппорт с периодическим фиксом багов. Ну и конечно же - оплата хостинга. Тут нужна команда, а не один человек. Да и все должно быть тщательно спланировано.
Лучше, надежней и проще будет купить сервак, и перенести все на него. Можно даже посадить на MYSQL, хотя я бы использовал Oracle. По поводу обновлений: пишем дополнение - апдейтер, который будет удаленно, с сервера, подтягивать все необходимые фиксы. Как вариант, можно саппортить заказчиков тим вьювером. Правда для коммерческого использования он платный.

0

@planar

У меня была подобная проблема. Помимо ее - еще и низко скоростное соединение. Решил с помощью "теневой синхронизации". То есть - одна машина выбирается ведущей, остальные ведомые. В определенное время ведомые подключаются к ведущей машине и забирают от нее изменения + передают свои. Правда СУБД у меня была изначально PostgreSql и все изменения в таблицах я регистрировал в другой таблице с помощью триггеров.

0

@Umka_

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

Еще на счет планирования вы правы на все 100%. Так и будет. Просто мне для начала надо по изложенным выше вопросам принять окончательное решение. Уже от этого и будем плясать с планированием.

0

@ArtOfLife

По порядку. Вы собираетесь сервак ставить у заказчика? Как по мне - не вариант. Лучше разместить его у себя. Будет спокойней и безопасней.
По поводу поднятия вэб-сервера у себя в обход хостеров. А на чем вы собираетесь поднимать вэб-сервер? Апач или гласфиш? Это не самая простая задача для того, кто этим никогда не занимался. Тут еще может возникнуть проблема, если вы ходите в инет через проксю. Надо будет просить админа, чтобы делал проброс.
По поводу апдейтера. Лучше реализовать вариант, когда он будет грузиться до самой программы, проверять список файлов на сервере, и, если есть какие-либо изменения, предлагать апдейтиться, если нет - запускать ПО. Можно реализовать в виде простенького интерфейса с прогресс баром для отображения статуса загрузки, и кнопкой с "подменой": если есть обновления, кнопка будет запускать событие "обновить"; если нет - запускать ПО. Как-то так.

0

@Umka_

Сервак ставить у заказчика. Это моя не официальная работа, так что дома он мне не нужен. Разве что для начальной настройки нужно будет взять и все сконфигурировать дома, чтоб у них в офисе не торчать.
Еще один момент. Если это будет веб-приложение, то я не хочу, чтоб сервак был виден отовсюду из инета. Нужно, чтоб люди из 4 городов могли на него зайти и поработать с программой. Смутно предполагаю, что надо будет смотреть в сторону VPN. Так же думаю, что в эту сторону надо будет смотреть в любом случае, даже если я буду делать вин-приложение. Надо, чтоб компы были в одной сети.

0

@ArtOfLife

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

0

@kenny69

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

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

0

@Umka_

Как работает прога:
Приходит клиент, ему дают каталог с дверями. Он выбирает, чего ему хочется. Дальше работник в моей проге создает договор, в договоре указывает характеристики дверей: модель, цвет, фурнитура, размеры, расположение, и другие параметры. По договору прога формирует бланк договора в ворд. Кроме договора еще формируется заявка для цеха.
Созданные договора группируются в так называемые листы. По этим листам печатается еще 4 штуки отчета для цеха: задания на сборку, покраску, сушку и упаковку.
У договоров в зависимости от стадии изготовления меняется статус: Новый, В цехе, Готов, Сдан.
В сущности в проге есть следующие основополагающие вещи: клиенты, модели дверей, виды фурнитуры, виды стекла, виды покрытий. Еще есть цены, по которым ведется история изменений, чтоб старые договора при изменении цены не пересчитывались. Все вертится вокруг этих понятий.
Еще сделан контроль работы цеха, но тут они переборщили со своими возможностями и просто не смогли выделить людей для работы с этим функционалом.
Во всех 4х филиалах работа организована одинаково. Только в филиалах они не печатают задания для цеха. Сейчас филиалы просто передают договора в центральный офис, а там уже все печатают.

Я думаю, что при организации единой БД я разграничу все правами и филиальные работники так же смогут только принимать договора, а центральный офис будет все это организовывать в листы как им надо.
Еще у Заказчика есть пожелания по доработке, пока что я про них не знаю, т.к. надо сначала определиться с подходом, а потом разговаривать.

0

@kenny69

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

Получается, что для каждого филиала будут просто обновляться цены и ассортимент из БД в главном офисе. БД клиентов для каждого филиала будет отдельная. БД из всех филиалов будет сливаться на БД в главном офисе -> надо отдельно разрабатывать функционал главного офиса и филиалов.

0

@Umka_

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

0

@kenny69

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

0

@Umka_

Всем большое спасибо за ответы! Что-то уже стало более понятно. Буду думать .

0

@StanislavSV

Я предлагаю такое решение:

Оставить ваше WinForms приложение как есть, но переписать код доступа к базе данных так, чтоб взаимодействие с БД происходило посредством веб-службы (asmx, как вариант), которую разместить на отдельном сервере. Это даст такие преимущества:

1) Пользователям приложения не нужно будет тратить время на переучивание , ведь не надо создавать новое веб-приложение.
2) Не нужно тратить усилия на синхронизацию баз данных(в случае winForms-приложений с локальной БД), так как БД одна, каждое клиентское приложение работает с ней, а не с локальной) (по мне - самое главное преимущество).
3) Усилия, которые нужно потратить на реализацию веб-службы и переписку кода доступа к данным гораздо меньше чем потраченные усилия на создание нового веб приложения или синхронизацию между БД. (Естественно при том, что код доступа к данным в вашем текущем приложении написан правильно/оптимизированно, тоесть, имеется разделение логики приложения на уровни - доступ к БД,
бизнес-логика, и т.д.)

0

@Umka_

Эх, в том-то и дело, что тогда, когда писалось это приложение уровень моих знаний оставлял желать лучшего . Необходимые знания и навыки появились только где-то через полгода после внедрения программы. Разделение не было сделано. Поэтому сейчас наверное лучше переписать вообще все.
Тут больше даже вопрос в том, за каким подходом будущее. Я вижу, что веб-технологии находят все больше приверженцев, поэтому и сомневаюсь в актуальности вин-приложений. А на последнем месте работы мы вели разработку вообще вот на этом: http://www.visualwebgui.com/. Не скажу, что я в восторге от этой технологии, но она своего рода компромис - веб-приложение, которое выглядит как вин-формс приложение.

0