Оптимальная выборка данных для контролов формы в сетевой базе

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

Вы не указали критериев оптиимальности. Поэтому вам не отвечают.
Что вы хотите оптимизировать?

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

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

хорошая подборка советов и ресурсов по вопросам "ускорения" (и, косвенно, некоторого увеличения общей устойчивости/надежности) интерфейса (если вы это понимаете под "опьдимизацией") на ангельском размещено здесь
http://www.granite.ab.ca/access/performancefaq.htm

на этом форуме ищите по тормозам.
найдете все или почти все собранные в указанной ссылке советы (как и ее саму).


зы.
для меня "оптимизирвать" безусловно ругательное слово, вызывающее рвотный рефлекс.
что-то вроде ответа на вопрос - кем ты работаешь? - Менеджером! (замените - оптимизатором - сможете удержаться от смеха?)

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

2 ищщин
> Вам отвечаю, потому, что вы производите впечатление вменяемого человека.
Польщен, спасибо.

> Столь же отвратительными, как оптимизация, только "изящные решения" могут быть.
Ну нет, я бы тут поспорил. Если нелениво, посмотрите мой топик "Обработка изменений полей в форме оптимальным способом". То, что я там вначале предложил никак нельзя назвать "изящным решением", согласны? А то, что предложил Саныч? По-видимому, да. Хотя можно назвать и обычной программистской практикой.

Да, тут я немного недоговорил. Поскольку база сетевая, думаю, что лишняя нагрузка на сеть ни к чему. Поэтому под оптимальностью подразумеваю снижение трафика. Так что правильнее было бы назвать "Ускорение выборки …" или "Снижение трафика при выборке …".
Попробую чуть прояснить задачу. На дереве – документы. Одна из вкладок в наборе отображает их отношения между собой. Первый список отображает отношения выбранного в дереве документа. Т.к. у одного документа м.б. много отношений, то документ : отношения = 1 : М. В свою очередь каждое отношение для выбранного документа тоже могут составлять несколько документов. Т.е. Документ1 дополнен документами (ДокументА, ДокБ, В и т.д.), изменен документами (ДокЖ, ДокЗ и т.д.) и т.д. Таким образом, второй список отображает документы, составляющие правую (в данном контексте) сторону отношений. Не запутал?
Теперь варианты:
1. Если бы это была несетевая база, я бы отдельным селектом заполнил первый список. При выборе строки в нем отдельным селектом заполнял второй список. Таким образом, каждый выбор строки первого списка инициирует прохождение некоторого объема информации, правда, относительно небольшого. В этом варианте на вкладке достаточно двух списков.
2. Поскольку база сетевая, мне кажется, что здесь должен быть другой подход. А именно – при выборе в дереве документа нужно сразу получить информацию и об его отношениях и о документах, которые их составляют. Конечно, при этом объем данных увеличится, но зато потом можно будет щелкать туда-сюда по первому списку, а выборка будет идти уже из локального полученного набора записей (Recordset?). Вот только как именно это сделать?

P.S. Можно я еще раз повторю свой вопрос из первого поста(?):
"И еще, имеет ли смысл делать выборку данных для контролов всех вкладок одним запросом (уменьшаем количество отдельных подключений, но тянем больше данных) или для каждой вкладки отдельно при переходе на нее (имхо, это лучше)?". Хотя, наверное, объем трафика что так что этак.

КД

> Столь же отвратительными, как оптимизация, только "изящные решения" могут быть. Ну нет, я бы тут поспорил. Если нелениво, посмотрите мой топик "Обработка изменений полей в форме оптимальным способом". То, что я там вначале предложил никак нельзя назвать "изящным решением", согласны? А то, что предложил Саныч? По-видимому, да. Хотя можно назвать и обычной программистской практикой.

Спорьте. Но не со мной. Мне это не интересно.
"Изящно" ли то, что предложил там Саныч - лучше спросить об этом у Саныча.
Для меня термина "изящно" как технического - не существует.
На мой взгляд, его смыслы целиком лежат в области культурных оценок.
Это даже к вторичным половым признакам трудно отнести - вроде бороды и усов.

Про бороду и усы достоверно известно, что со временем они растут.
А что с "изящностью" со временем происходит - увеличивается она или уменьшается?

КД

...<многа букав>...

Извините, я лично не знаю как на это отвечать.
"выбрать все" - никак не соотносится с "экономией трафика".
Что-то из "выбранного всего" ведь может оказаться не нужным выбирающему на форме.
касательно реактивности интерфейса "потом, после выбора всего в локальный кеш" - да она будет выше.
Это тем более оправдано, чем более статический характер имеет отбранная информация И чем больше у нее потенциальных пользователей. Так часто поступают с информацией вроде "справочников" при разработке приложений на базе серверов приложений/веб серверов.
Примите в расчет, что при наличии динамики в данных конструкция резко усложняется за счет необходимости поддержки механизма синхронизации.
Если хотите и это приемлемо для ваших задач - отбырайте все в локально созданную временную базу, к которой уже и привязывайте рекордсеты форм.

КД

P.S. Можно я еще раз повторю свой вопрос из первого поста(?): "И еще, имеет ли смысл делать выборку данных для контролов всех вкладок одним запросом (уменьшаем количество отдельных подключений, но тянем больше данных) или для каждой вкладки отдельно при переходе на нее (имхо, это лучше)?". Хотя, наверное, объем трафика что так что этак.

Этого я не знаю.
Сформулируйте себе, в чем заключается смысл (цель, которую желается достигнуть)
и оцените приемлемость возникающих накладных расходов.
(т.е. попробуйте так и эдак. )
...........................................

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