artemanaSergSuperпропущено...
нет, не альтернативным
всё именно идет к тому что будет либо вэб-интерфейс, либо терминал
Как и куда все пойдет, сказать не берусь. Но то, что архитектура с локальной копией данных вполне эффективна, и обладает рядом преимуществ, как с точки зрения производительности, так и надежности для меня является доказанным фактом.
SergSuperпропущено...
что плохого то? пользователи подчас и не подозревают что они "сидят в матрице"
Зачастую тормозит. Уравниловка. Мощности локальных машин есть, но не используются.

На каком сервере под терминал могут тормозить 10-15 пользователей? У одного клиента когда-то такое наблюдал на одноядерном атлоне с 512мб озу. Но такое железо снято с производства лет 6 назад. Локальных машин может и не быть. Попробуйте поставить терминальные станции. Они хоть и не дешевле обычных компьютеров, зато имеют немало преимуществ. Например, вместо гудящего ящика под ногами куда приятнее моник на небольшой подставке и тишина, аж противно становится. Срок службы в 2 раза больше, потребление электричества значительно ниже, не требует настройки и инсталяции какого-либо софта (только строчка коннекта к серверу). В чем сейчас основная проблема использования компьютеров с точки зрения обычного пользователя? Их сложность. Даже специалисты зачастую не понимают, что происходит внутрях работающего софта. Поэтому и надеются вынести вычисления в "облака", предложив юзерам снять головную боль с установленным локально софтом.
А почему как аксиома воспринимается, что локальная работа на множестве отдельных машин будет быстрее, чем на терминальном сервере? Простой пример. Делает юзер оборотку по товарам за три последние месяца. Что произойдет? Данные будут считываться с жесткого диска. На терминале достаточно одному пользователю выполнить эту операцию, все остальные будут дергать информацию уже не с диска, а из общего кэша в оперативной памяти, что в несколько раз быстрее. Переполнится кэш? А какой размер баз данных у большинства бизнес-пользователей и сколько оперативки можно (недорого) поставить на сервер?
Другой пример. Сформировал юзер отчет. Через пару минут другой хочет тот-же отчет с теми-же параметрами. Почему бы ему не предложить взять готовый у первого? И не тратить время на новый расчет?
Еще пример. Предположим, что есть некий открытый период, в который вносятся изменения. Затем решили, что можно его сократить. Закрываем более поздней датой. В закрытом периоде сохраняем готовые результаты для наиболее восстребованных запросов. У всех пользователей на терминале скорость построения отчетов по данным закрываемого периода взлетает на порядок.
Я прекрасно понимаю, что есть некая система, успешно внедренная у многих пользователей. Выработались определенный стиль мышления, определенные стандарты. Но важно не только сохранять сделанные инвестиции, но и смотреть, как приспособить имеющуюся технологию к новым реалиям. Почему не попробывать с приемлемыми затратами приспособить имеющийся софт к работе на терминальных серверах? Тем более, если как у Викты, используется файловая база. Это же не переписывать весь софт в клиент-сервер или web. Пусть в этой системе логическим пользователем будет терминальный сервер, а распределение нагрузок перенесем на несколько серверов, как в старой системе. Тогда и пользователей можно подключить на 1-2 порядка больше, а это уже горизонты для старой системы...

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

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

Возьмем, к примеру, любое среднее производственное предприятие с численностью сотрудников около 1500. При хорошем уровне автоматизации, ERP система должна насчитывать ну никак не меньше 100 рабочих мест. Заметим, речь идет об одной, единой системе, а значит все хранится в одной центральной БД. Заметим так же, что такие системы хоть и не работают с гипертрофированно большими объемами данных, например характерными для билинговых систем, разместить все базу в оперативной памяти сервера не выйдет. Но это еще пол беды. Информационная модель современной ERP-системы чрезвычайно сложна, а значит, в ней есть много таблиц (=>10^3) и связей между ними. Основных причины две - сложность предметной области и притязания на универсальность решения. В такой системе неизбежно возникают массовые одновременные чтения, так как она призвана решить широкий круг относительно независимых подзадач. Работа складского хозяйства не особо связанна с работой ОТиЗ, или работа одного склада с работой другого. Всем и часто от системы что то надо, кому то надо что то ввести, кому то надо что то посмотреть. Причем ввод, это же непросто импорт с какого то источника, он неизбежно сопровождается чтением. Вводим счет на продажу, читаем словари - товары, валюты, курсы, контрагенты, прайсы, читаем и анализируем правила бизнес логики и прочее и прочее и прочее. А если учесть возрастание потребностей пользователей в интервалах подготовки периодической отчетности, то как можно говорить об отсутствии массовых, различных и одновременных читающих обработок (сложных и простых)? Может быть не надо было строить такой большой завод?

Нам в GrossBee , как и разработчикам Викты, использование свободных мощностей рабочих станций, кажется разумным решением. Есть ли другие варианты решений? Да! И среди них тьма вполне успешных работающих!! А зачастую ни какая локальная копия данных под некую задачу и не нужна!!! Но при прочих равных условиях, ERP системы с локальными усеченными копиями БД, могут работать и работают быстрее.
В данной теме изначально писали о гораздо более скромном количестве пользователей. Для 100 может, конечно, одного терминального сервера и не хватить, зависит от сложности выполняемых задач. Но все равно я не поверю, что работа на 100 отдельных машинах будет эффективнее, чем работа на 2-3 терминальных серверах.
Все еще сильно зависит от прикладного приложения. Например, мне сложно представить, о каких объемах информации, не помещающихся в ОЗУ, идет речь. Когда-то прикидывал, если 200 накладных в день, то за год это ~50-60мб в таблице шапок, в пределах 200-300мб в строках (для торговых контор, для производства последняя цифра должна быть существенно меньше). Пусть будет больше 200 накладных, в базе все равно редко имеет смысл держать более 3-4 лет. И в ОЗУ грузить старые данные далеко не всегда надо, чаще можно оперировать готовыми итогами. Чтения же всяких значений и бизнес-правил из номенклаторов на терминальных серверах происходит так-же быстро, как при локальной работе - сотые доли секунды для файловых баз.
Могу предположить, что архитектура используемой системы такова, что для универсальности все операции своливаются в одну-две огромные таблицы. Количество таблиц более 1000 тоже наводит на вопросы. Это же не САП с огромной историей развития. Можно делать и комбинированные таблицы (например, шапки складских документов или производственных документов, их же строки и т.п.), тогда количество будет значительно меньше.