модКонкретный вопрос: на чем писать клиента что бы работало по удаленке на обычном канале 64к и без СП ? Толстого не предлагать !
Без разницы на чем писать, важно - как писать. При желании я Вам и на обычном Паскале напишу интерфейсную часть И будет работать... Сейчас обычные Win32 приложения у меня работают напрямую с MSSQL через ODBC. В прошлые выходные, например, набивал накладную в Питерской БД прямо из поезда(есть у меня такое право)-винца захотелось по приезду

VladiCh systemRвместо того чтоб покупать под СП новый сервер, платить за винду/линух, $20K за iAs и прочее, а вложить это бабло в память серверу субд, то эфективность этого вложения будет несоизмерима.
Бр... При чем тут iAS? Я не собираюсь это барахло покупать. Можно конечно и память СУБД нарастить, не вопрос. Только это не решит вопрос ручного управления кэшированием, а не так, как этого захочет СУБД. Если только не загрузить базу данных полностью в память. Тогда конечно да... Не нарастите мне память сервера СУБД гигабайт до 200? Ну хотя бы до сотни? Во сколько это обойдется? :)
А можно вопрос, это под какое кол-во пользователей столько памяти Вам нужно?

Искандер ДвурогийА меня так и тянет сказать - а зачем вообще нужен сервер БД? Лицензии какие-то, черный ящик. Давайте все в dbf обрабатывать, программой на Турбо-Си, c ассемблерными вставками. Ух, летать будет. И полный контроль. Если еще под процессор видеокарты оптимизировать, да его задействовать ....

А транзакции вручную отрабатывать?

Искандер Двурогий
Ребята - есть простые аксиомы спеца по ИТ - нет универсальных решений, нет устаревших решений, нет наилучших решений. Всюду компромисс. Все должно быть в меру, средства должны соответствовать задаче. Если вы не видите суслика ... А он есть!

Согласен, только от всех этих компромисов у большинства существующих систем бАльшие проблемы с производительностью. И именно поэтому у нас будет еще много работы

Искандер ДвурогийА меня так и тянет сказать - а зачем вообще нужен сервер БД? Лицензии какие-то, черный ящик. Давайте все в dbf обрабатывать, программой на Турбо-Си, c ассемблерными вставками. Ух, летать будет. И полный контроль. Если еще под процессор видеокарты оптимизировать, да его задействовать ....

Про работу в сети большого кол-ва пользователей вообще можно забыть...

Сисой
Вы наверное, понимаете, что насчет dbf - это мой сарказм.


Сисой
Но в каждой шутке есть доля шутки... Я встречал такие приложения на dbf, что закачаешься. С решением вопросов построчной блокировки (при помощи доп. таблиц для Insert и Update), с собственными параллельными менеджерами транзакций (и откатом оных), в общем, голь на выдумки хитра. Реально видел 400-500 нормально работающих юзеров в системе (правда, объем ОЗУ сервера был примерно равен объему БД).

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

Сисой
Но есть еще один СП - сервер блокировок. Предназначен для групповой работы одновременно 10-30 разработчиков. Сама система - типа 1С, с выделенным логическим объектным слоем, поддерживающая объектно-ориентированное проектирование (т.е. таблицы и методы работы с ними тоже наследуются, наряду с формами и репортами). Система поддерживает формальную непротиворечивость, т.е. нельзя как-то (например, через макроподстановку) незаметно обратиться к таблице БД или ее реквизиту в нарушение структуры БД.

Так эту целостность СУБД поддерживает вообщето...

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

отредактировано модератором

VladiChСервер СП администрировать не нужно, кроме включить/выключить/переустановить. Так что отдельный админ для этого точно не требуется.
Любопытно, а как тогда организовывается доступ к нему юзверей? Типа, заходи кто хочет?

Mainframe OTiger VladiChСервер СП администрировать не нужно, кроме включить/выключить/переустановить. Так что отдельный админ для этого точно не требуется.
Любопытно, а как тогда организовывается доступ к нему юзверей? Типа, заходи кто хочет?
А зачем для организации доступа пользователей отдельный администратор? у нас что-то около 15 тыс. пользователей и ни одного отдельного администратора для пользователей. ходят туда, куда положено.
Куда положено говорите, а кем положено? Кто этот человек или отдел? А текучки кадров нет, люди работают от института и до пенсии? Приходят новые люди, кто им права раздает?

ВМоисеев>OTiger
>Ну сервер то ладно, а что у них за сетка была?, ...

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

Это уже давно реализовано в СУБД, к чему велосипед?

ВМоисеев
Число серверов приложений значительно меньше числа клиентов ("магические" числа - 4,8,16). Их число опредляется разумностью (оптимальностью) загрузки сервера данных. Они могут располагаься на отдельных компьютерах локальной сети или (в принципе) и на компьютере сервера данных.

Точно также создаются кластеры серверов-в зависимости от загрузки...

ВМоисеев
Каждый СП анализирует очередь запросов, при наличии заказа обрабатывает его и помещает результат (ответ) в очередь ответов и соответствующий клиент забирает нужный ответ.

Ну и смысл, если это реализутеся и без СП?

ВМоисеев
СП жестко контролируют запросы. Никаких SQL предложений в запросе - только идентификатор функционала и его параметры, и никогда не будет передан клиенту ответ размером со всю (гигантскую) таблицу и т.п.
С уважением, Владимир.
Ну и зачем для решения такой задачи здесь СП?
Вообще напоминает про испорченный телефон...
1. Клиент подает запрос в СП
2. СП тратит время на обработку этого запроса
3. Посылает фактически новый запрос в СУБД
4. СУБД отрабатывает запрос
5. Возвращает результат в СП
6. СП отрабатывает результат
7. СП посылает ответ клиенту
Большего "пи-пи-пи" в жизни не видел
Это я еще не учел трафик между клиентом и СП, СП и СУБД, тобишь в 2 раза больше чем при 2-х звенке.
Про время выполнения всего этого барахла можно даже не упоминать...

Тут в одной из тем человек задавал конкретный вопрос: Требовалось, чтобы система позволяла набить документ с 15-20 позициями в течении минуты. И как то все скуксились на этом вопросе. - Теперь я понимаю почему!!! С такой технологией это действительно малореально, если только клиента не подсадить еще на кучу бабла, для покупки новых серверов и увеличения мощностей имеющихся. Ну и ессно чтоб сеть поменять с 10 на 100-1000мб.

softwarer OTigerТут в одной из тем человек задавал конкретный вопрос: Требовалось, чтобы система позволяла набить документ с 15-20 позициями в течении минуты. И как то все скуксились на этом вопросе
Хм. Имхо это возможно в любой технологии с нормальным клиентским интерфейсом (веб, полагаю, как всегда окажется в пролете). Если, конечно, оператор в состоянии с нужной скоростью нажимать кнопки :) Для этого по сути нужно одно: позиции документа должны выбираться мультиселектом, надергал - проставил количество - вперед. Не вижу тут особой разницы в количестве звеньев после клиента.
Мультиселект несколько неудобен, если необходимо резервировать выбранный товар. Окно с остатками висит гораздо дольше(теряет актуальность).
Но да бог с ним, с мультивыбором, тогда мало кто смог предложить решение...

отредактировано модератором

iscrafmскрость ввода определяется только заточенным под ввод конкрентных данных интерфейсом и скростью пальцев . От звенности приложений абсолютно никак не зависит. На рис. ниже форма ввода заказа из торговой системы. Проектировалась специально под технологию заказа клиента принятую на конкретном предприятии. Слева список доступных позиций на складе с мгновенным поиском и специализированными фильтрами. Справа корзина. Выстроена цепочка в которой все делается в основном клавишей Enter. За минуту успел вбить 43 позиции в заказ, с учетом отсутствия на ноутбуке цифровой клавиатуры.
Для перебивки данных в телекомовской системе вообще использовался "слепой" ввод. Операторы работали с такой скоростью, что за время ввода успевал только клавишу на клавиатуре найти.
В первом примере трехвенка, во втором всего 1 звено.
Как скорость ввода данных завязанна на количество звеньев в системе?
Дык в однопользовательском режиме даже 1С шуршит
Вы спрашиваете, как скорость ввода завязана на кол-во звеньев? Посчитайте сами, чуть Выше я приводил пример работы с СП по пунктам. Там их 7. В случае 2-х звенки их будет всего 3. Еще нужны объяснения?