Поиск архитектурного решения для поставленной задачи

Доброго времени суток всем.

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

Есть приложение:
делфи (Berlin)
декстоп (VCL)
работа с БД (My SQL 5.5) НД (FireDAC)
функционал - специализированная ERP под "HR кухню"

Приложение на данный момент - классический клиент-сервер, работа идет в локалке (клиенты 100 мбит и wifi, сервак 1 Гбит)


Особенности (требования заказчика и/или "удобство работы"):

- минимум модальных форм, максимум интерактивной правки данных
(как это выглядит - пользователь непосредственно редактирует записи в dbgrid (DBGridEh) без кнопок
сохранить, применить, отмена и. т.д. в некоторых местах есть но мало)
- почти на каждой форме (АРМе) присутствуют фотки (DBImageEh)
- присутствует многопоточка (пока эпезодически но есть планы по внедрению всяких sheduler и .пр.)

Сейчас одновременно работает примерно 6 пользователей
база за год подросла до 100 Мб - пока полет нормальный НО

Заказчик растет развивается и хочет открыть филиалы в городах при этом работать с общей базой.

И С ЭТОГО момента у меня реально ступор (все проекты (большие на работе) в которых работал и работаю по
своей специфике просто другие)
как обеспечить нормальную производительность (транспортные издержки) при удаленной работе
учитывая особенности (см. выше) - вот главный вопрос

вижу 2 пути

либо это главная база + несколько филиальных баз и синхронизация между ними
минусы - сложная синхронизация, возможная неактуальность данных + за всем этим зоопарком надо следить

уйти полностью в WEB (для делфы самый короткий путь это
клиент UniGui (dll для IIS) размещенный на VPS рядом с БД) - т.е. вся работа будет в браузере
минусы - ну по сути трудоемкая миграция, сырость UniGui (ehliba там нет и тд и тп) ну и вообще
мне декстоп в качестве ERP как то симпатичней

есть еще вариант с многозвенкой но чем мне здесь может помочь СП ? снимет нагрузку с БД ? с клиентов ?
а трафик мне кажется только возрастет как и сложность всей системы

здесь же не тот случай когда у нас идет пачка данных которые можно как то покрутить в промежуточном буфере
если другие части системы лагают (отстают)
здесь
реакция юзверя--dbavare---http--БД и обратно (в локалке то замечательно)



кто еще какие варианты знает подскажите

что сделал для того чтобы это приложение не загнулось сразу же )))

- во первых редактирование в gride в режиме cash update
(борьба с транспортными издержками и зависшими транзакциями)
- максимум ХП в базе (тригеры, курсоры и пр.)
(борьба с транспортными издержками - надеюсь сервак выдюжит)
- в aftescrol попадают только сжатые BLOB (thumbl) а сами BLOB в отдельной табличке
и доступны по ключу
(борьба с транспортными издержками + высокая нормализация БД)
- применение битовых масок
(борьба с транспортными издержками, экономия процессорного времени, экономия дискового пространства)
- эффективные алгоритмы
(надеюсь)




Р.S.
Тестил работу проги в том состоянии в каком есть сейчас на бесплатном VPS (azure / bizpack)
честно - не впечатлила скорость (сервак конечно тот еще унылый - но другого бесплатного нет)

0

если клиентов серьезно не увеличится, то текущее ПО выдержит. подкрутить работу с кешем + обработка потери соединения + выполнение критических операций втранзакциях
но если больше 20 одновременно, то
или веб
или трехзвенка

Сообщение от kebot есть еще вариант с многозвенкой но чем мне здесь может помочь СП ?

можно создать очередь на запись\чтение и ваши пользователи всегда будут с правильными данными
хотя по скорости вопрос то конечно останется

Сообщение от kebot хочет открыть филиалы в городах при этом работать с общей базой.

какой доступ к серверу? vpn?

читали на wiki.embarcadero рекомендации по работе Firedac на медленных каналах?

0

общий совет один тут
посмотрите современные web-приложения
много видели в них Delphi - гридов? treeView ? другой привычной классики?
знаете почему?
в вебе так работать невозможно.
лучший для вас вариант это скорее всего сделать веб-сервер и клиента на делфи
сервер можно тоже на делфи если не боитесь datasnap
или прямо web-сервер на делфи, тоже можно
проще всего сервер ваять на php

общаться программа с сервером будет обычными HTTP - запросами. гонять Json туда-сюда например.
В этом случае очень улучшается возможность сделать и мобильные приложения и даже альтернативного чисто-веб клиента

а вот на UniGui надо все равно полностью переписывать программу под предлагаемый набор компонентов
и выглядеть она будет странно, и ресурсы сервера жрать как не в себя

0

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

0

будет как в налоговой вечно. ой, у нас компьютеры висят...)

0

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

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

0

0