pkarklin MainFrame1.Речь от сревера приложений плавно перетекла к многоуровневым приложением, поэтому и пример приведен приложения, где многокомпонентность необходимая вещь.
2. А при чем тут расширение. Приложение должно работать на файловом сервере (сервер базы данных - это свосем другой сервер), иначе оно не может задать квоты учетной записи.

1. Ок. Согласен.
2. Ну так и пусть себеработает. А запускать его будет расширенная хп.
Разве важно кто кого запускает? Важно , что логику работы программы реализуют совершенно разные приложения, работающие на разных серверах. Это если о многозвенной говорим. А кто кого запустил - это же не имеет значение. Мне как раз в этом всем нравиться, что нет четко выраженного сревера и клиента. Но это лирика.

pkarklin MainFrame НО и первый вариант не выход. На нем производительность недопустимая.

Это единственно правильный выход, IMHO. А вот для повышения производительности есть множество путей...

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

Terrorist автор1. Можно каждый раз, обработать ответ и выбирать из базы только тот вопрос, который нужно по результатам ответ показать. Сто вопросов - сто обращений к базе. ДВести пользователей одновременно тестируются - много обращений.


Гм.... если обращение к базе это:
Коннект-селект-дисконнект, то будет тяжело, но если запросы делать по существующему соединению, будет гараздо быстрее. А руками писать джоины и перебор вопросов, вместо того, чтобы использовать уже написанное + можно индексы подвязать, это ИМХО мазахизм.
Можно и индексы, но в силу определенных причин (удовлетворение некоторой спецификации) на те данные, которые участвуют в правилах адаптационного теста индексы привзяать нельзя (они привязаны к другим данным, которые используются в других ситациях). Данные извлекаются фактически из BLOB. и всякий раз снова и снова выбирать из BLOB искать внутри и выбать следующий?

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

Решения по оптимизации... Без какой-либо конретики в симптомах... Мдя...

Кстати...


MainFrameОбращений к базе меньше в сто раз. Нагрузка ложиться на сервер приложений.

Ну и в чем "фишка" такого, с позволения сказать, распределения?! Вместо одного сервера, нужно два! Придеться реализовывать на сервере механизм кэширования, что уже реализовано в самой СУБД?! Зачем эти городушки?!

Хуже того - три! Так как приходится и севрер приложений распрделять. НО с тремя серверами задача решается - достигается нужная производительность при нужном числе пользователей. А с одним (было у нас, поэтому есть с чем сравнить), не решается никак. Проивзодительность недопустимая.

pkarklin MainFrameДанные извлекаются фактически из BLOB. и всякий раз снова и снова выбирать из BLOB искать внутри и выбать следующий?

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

Terrorist
MainFrame
Данные извлекаются фактически из BLOB. и всякий раз снова и снова выбирать из BLOB искать внутри и выбать следующий?


И опять мы приходим к тому, что просчеты в проектировании структуры хранения выливаются в дополнительные навороты с сервером приложений и т.п. Печально все это... :(

Полностью согласен. MainFrame , кто Вас заставлял поля по которым идет выборка засовывать в БЛОБ?
Реальность заставила. потому что другиевопросы с BLOB решались на порядок быстрее (в другом месте и атм это было так же среьбзно) и во-вторых, какое имеет это значение? Как бы мы не индесировали - сто обращений к базе не сравним с одним. При этом структуры сложные, и даже если бы в этмо месте обошлись без BLOB теряли бы на другом после каждого обращения пришлось бы составлять сложную структуру - проще найти уже в созданных - поверьте, это на порядок быстрее. А все струткуры заполняются в самом начале, потом нужно находить только определенные поля. Т.е. мы в самом начале готовим все для отображения. и только говорим , что именно отображать. А там пришлось бы всякий раз не только к базе обращаться, но и из результата делать заготовку и только потом отображать - это долго.