Что быстрее? Запрос к локальной таблице или списку запрограммированных значений в элементе управления combobox

Question

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

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

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

Кто-нибудь знает, дает ли использование жестко запрограммированного списка значений в поле со списком прирост производительности по сравнению с локальным запросом к локальной таблице в MS Access? Я использую MS Access 2016, если это помогает.

Answer 1

Хорошо, несколько вещей: вы НЕ хотите использовать сквозной запрос для списка / поля со списком. НИКОГДА !!!!

Почему? Клиент Access не может фильтровать PT-запрос. Здесь это кажется противоречивым.

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

Однако давайте предположим, что поле со списком большое - скажем, 3000 строк.

И ТАКЖЕ предположим, что поле со списком привязано (это означает, что оно сохраняет значение в привязанный набор записей формы.

Хорошо, помните приведенное выше правило !!! - Клиент доступа НИКОГДА не может фильтровать запрос PT.

Итак, если у вас есть отчет, который вы запускаете? Если ваш запрос PT не ПРЕДВАРИТЕЛЬНАЯ ФИЛЬТРАЦИЯ (критерии существуют в запросе PT - даже в хранимой процедуре), тогда добавление предложения where в форму (или отчет), или в этом случае поле со списком НЕ БУДЕТ РАБОТАТЬ - возвращается ПОЛНЫЙ набор данных, который не может быть отфильтрован.

Итак, если у вас есть запрос PT с 500 000 строками, и вы делаете это:

docmd.OpenReport "rtpInvoice", acViewPreview,,"InvoiceNumber = 1234"

Вышеупомянутое будет вытягивать 500000 строк.

Однако, если вы использовали связанную таблицу с самолетом Джейн или лучшую ссылку на представление, и она ТАКЖЕ имеет 500000 строк ? По сетевой трубе сходит только 1 запись! * 10 20 *

Итак, если это поле со списком привязано к 5000 строкам, и происходит простая навигация к СЛЕДУЮЩЕЙ записи? Ну, поле со списком, конечно, будет иметь одно значение - базовый набор записей связанной формы. Но он не может фильтровать + отображать ОДНО значение для поля со списком (большинство полей со списком многостолбцовые - 1-й столбец = PK, а 2-й столбец = какое-то описание.

Таким образом, доступ на самом деле довольно умный , и он будет пытаться получить ТОЛЬКО ОДНО значение из 5000 строк, управляющих комбинированным окном. Но исключением из правила, конечно же, является запрос PT!

Опять же: клиент доступа не может фильтровать запрос PT.

Итак, если поле со списком содержит большой набор данных И ТАКЖЕ загружается запросом PT, тогда все идет медленно, как собака. У меня была одна система, в которой запрос PT возвращал около 100 000 строк. Просто простая навигация к следующей записи была медленной, как собака.

Замена запроса PT на связанный вид заставила форму работать практически мгновенно. Это связано с тем, что из 100 000 строк Access может извлечь ТОЛЬКО ОДНУ строка для отображения поля со списком и этого 2-го столбца.

Итак, хотя запрос PT - это самый быстрый способ получить данные? Да, 100% верно, но вы хотите использовать ТОЛЬКО эту скорость d преимущество, КОГДА вам нужны ВСЕ записи этого запроса PT. Если вы собираетесь фильтровать ПОСЛЕ или ПРОТИВ запроса PT (например, как это делается для связанного поля со списком), то будет выполнено полное сканирование всех записей, управляющих этим полем со списком.

Лучший подход? Сбросьте запросы PT для поля со списком и замените их связанными представлениями. Вы даже можете указать сортировку в представлении (да, он попадает в верхние 100%). Так что помещайте ТОЛЬКО имя представления в поле со списком - не запускайте построитель запросов.

И вы даже можете уйти, используя прямую ссылку на связанную таблицу. Опять же, клиент Access может фильтровать этот набор данных для поля со списком.

Таким образом, нет необходимости тратить все время разработчика на создание запроса PT для поля со списком, и нет необходимости (или преимущества в скорости ) пытается использовать код для загрузки и заполнения поля со списком. Но если запрос PT вернет более 30 строк, тогда вы хотите сбросить запрос PT и использовать связанную таблицу или, что еще лучше, связанное представление.

Я бы не стал возиться с перетаскивание таблицы с сервера на локальный - вы могли бы это сделать, но это просто лишний код, лишняя боль, и это действительно очень мало для вас. И часто это может усугубить ситуацию. Зачем вытаскивать целую таблицу из большого количества строк для поля со списком, когда вы просто запускаете форму, доступ достаточно умен, чтобы вытащить ТОЛЬКО одну строку, необходимую для отображения поля со списком. Он не будет извлекать данные, пока вы не нажмете на комбо, чтобы сделать выбор.

Если ваши запросы PT содержат более 50 или 100 строк для заполнения поля со списком, а это поле со списком связано с окном со списком? Затем вам нужно сбросить запрос PT и использовать связанную таблицу / представление - и вы получите гораздо лучшую производительность.

Answer 2

Вместо использования таблиц, связанных с SQL сервером, рассмотрите возможность использования локальных таблиц для любых значений, которые редко меняются, например для стран.

Держите главные таблицы на сервере SQL. Когда требуются изменения, обновите главную таблицу, а затем импортируйте в свой интерфейс перед развертыванием.

Таким образом вы получите лучшую скорость, чем при работе с нелокальными таблицами, и сможете использовать эти таблицы в запросах и т.п. И поскольку одни и те же данные хранятся как во внешнем интерфейсе Access, так и во внутренней части сервера SQL, вы все равно можете создавать представления на сервере SQL, используя те же данные.

С уважением,