Ну, какова скорость соединения inte rnet по сравнению с локальной офисной локальной сетью?
Даже самая дешевая офисная сеть в наши дни составляет 1000T. Раньше они были 100Т, а до этого были базовые 10Т.
Итак, это действительно простая математика 3-го уровня.
Допустим, ваше inte rnet составляет 15 Мбит. Черт возьми, допустим, это 50 мибт. Но опять же, это ваша скорость загрузки !!! Когда вы попадаете на рабочий сервер, THAT END ограничен скоростью его загрузки. И даже при хорошем плане эта скорость загрузки ограничена.
Итак, давайте займемся математикой для третьего уровня. Предположим, что ваше соединение ite rnet составляет 50 Мбит (это может быть одностороннее, но я ОЧЕНЬ сильно сомневаюсь, что ваша скорость загрузки оценивается так хорошо.
Итак, 1000/50 = 20!
Вау !!! В 20 раз медленнее!
Хорошо, теперь мы спрашиваем: почему 20-кратное медленное соединение становится в 20 раз медленнее? Как сказал бы Гомер simpsion? Ах !!!
Итак, 4-секундная задержка теперь составляет 80 секунд !!! Но опять же, я ДЕЙСТВИТЕЛЬНО сомневаюсь, что у вас есть что-то, близкое к 50-битному соединению - и когда вы попадаете на сервер, вы ограничены не скорость загрузки, так как вы загружаете с этого сервера. Итак, теперь вы ограничены скоростью загрузки. Скажем, 15 МБТ. Хорошо, давайте сделаем еще несколько математических вычислений для третьего уровня:
1000/15 = 66!
Хорошо, теперь мы в 66 раз медленнее. Теперь 5-секундная задержка будет 5 x 66 = 333 секунды (или ПЯТЬ И ОДНА ПОЛОВИНКА!).
Итак: Нет, ваш inte rnet соединение может быть быстрым, но С ЧЕМ вы сравниваете эту скорость? Поскольку, если вы сравниваете ее с вашим дешевым офисом сеть с рейтингом 1000Т? Что ж, тогда вы даже не близко, и по всем стандартам ваше inte rnet соединение НЕ БЫСТРО!
Я имею в виду, что вы можете быстро ходить, но вождение автомобиля - это ОЧЕНЬ другой процесс.
Конечно, вы можете сделать одну вещь - убедиться, что формы доступа НЕ извлекают много данных.
Итак, если вы свяжете форму с таблицей с 500 000 строками?
Ну а если ПРОСТО запустить форму? Затем он начнет извлекать данные. В конце концов, он делает ТОЛЬКО то, что вы говорите Access.
Однако, если вы сделаете это:
dim strInvoiceNum = InputBox("What invoice number")
docmd.OpenForm "frmInvoices" ,,, "InvoiceNum =" & strInvoiceNum
Итак, та же самая форма привязана к связанной таблице из 500 000 строк? Только ОДИН ряд пройдет по сетевой трубе. Итак, хорошая производительность - это В первую очередь вопрос хорошего дизайна. Если ваши дизайны предписывают Access собирать много данных в форму? Тогда вы ОЧЕНЬ заметите замедление. Но вы НИКОГДА не замечали этого раньше, потому что вам НЕ нужно было беспокоиться об ОЧЕНЬ ОГРАНИЧЕННОМ соединении rnet по сравнению с 50-кратной или более скоростью соединения, которая была у вас с офисной LAN.
Итак, потому что у вас было такое хорошая скорость раньше, тогда вам никогда не приходилось тратить время на беспокойство о том, сколько данных вы втягиваете в формы, и, следовательно, вам было все равно.
Теперь, выше, я использовал поле ввода, но в типичном приложении доступа вы создаст приятный пользовательский интерфейс и красивые формы, которые подсказывают пользователю, над чем работать.
Это не сильно отличается от того, как работает Google. Вы не загружаете ВСЕ rnet в браузер, а затем нажимаете ctrl-f для поиска ОГРОМНОЙ страницы с тоннами данных. Что вы делаете, так это запрашиваете - ищите, отображаете некоторые результаты, а затем позволяете пользователю выбирать результаты.
Затем вы запускаете форму с предложением «where». Итак, даже для формы, на 100% напрямую привязанной к большой таблице? Если вы откроете его с помощью предложения where? Он вытягивает только 1 запись или несколько записей по сетевому каналу.
Итак, вы можете сказать, что создайте форму поиска, подобную этой: введите описание изображения здесь
Я набрал smi. Итак, в событии после обновления текстового поля I go:
me.RecordSource = "select * from tblCustomers, где LastName как '" & ttextbox & "*'"
А когда пользователь нажимает на результат? Я открываю форму для ONE reocrd с предложением where:
например:
Docmd.OpenForm "frmBooking",,,"ID = " & me!id
Итак, даже если таблица, которую я ищу, имеет 100 000 или даже миллион строк? Ну вытащить 30 записей или кликнуть по строке? Итак, приведенное выше открывает форму для одной строки (и это ДАЖЕ, если форма привязана непосредственно к огромной таблице - извлекается только ОДНА строка).
Фактически, будь то пакет бухгалтерского учета, Google или ЛЮБОЕ программное обеспечение, которое вы когда-либо использовали? Формы не извлекают всю таблицу, и ЗАТЕМ вы используете ctrl-f для поиска ОГРОМНОГО набора данных, который вы удалили без уважительной причины. 5 пользователей в типичной офисной сети должны были обеспечить производительность BLISTERING. Однако, если вы используете VPN или соединение inte rnet между Access и серверной частью? Ну тогда бэкенд не может быть файлом accDB (доступным). причина в том, что сеть общего доступа к файлам имеет тенденцию быть слишком медленной для скорости inte rnet.
Однако, если вы примете приведенные выше советы по производительности для Access и серверной серверной части? Тогда да, вы можете получить довольно приличную производительность - но только если вы, разработчик, потратите немного времени на ограничение данных, которые вы вводите в такие формы.
Независимо? На основе простой математики для 3-го класса? У вас вообще нет быстрого соединения по сравнению с тем, что было до введения rnet integer между доступом и серверной базой данных.