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

Доброго времени суток всем.Нужен совет - как построить структуру работы приложения для моей текущей задачи. (не пинайте ногами - во первых больно ), во вторых все мы учимся)Есть приложение: делфи (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) честно - не впечатлила скорость (сервак конечно тот еще унылый - но другого бесплатного нет)
5 ответов

если клиентов серьезно не увеличится, то текущее ПО выдержит. подкрутить работу с кешем + обработка потери соединения + выполнение критических операций втранзакциях но если больше 20 одновременно, то или веб или трехзвенка
есть еще вариант с многозвенкой но чем мне здесь может помочь СП ?
можно создать очередь на запись\чтение и ваши пользователи всегда будут с правильными данными хотя по скорости вопрос то конечно останется
хочет открыть филиалы в городах при этом работать с общей базой.
какой доступ к серверу? vpn?читали на wiki.embarcadero рекомендации по работе Firedac на медленных каналах?


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


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


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


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