MS Access, изменяющий связанную таблицу на AWS MySQL Db, замедляет формы / отчеты

Question

Я новичок в новой должности в компании, где они используют MS Access с базой данных MySQL, работающей на сервере, который физически находится в нашем офисе за нашей частной сетью.Я был нанят для разработки совершенно нового приложения, чтобы привести компанию к современным стандартам.По мере того, как мы переносим функции / модули в новое приложение Angular / NodeJs, которое я пишу, пользователям все еще необходимо использовать пользовательский интерфейс, предоставленный MS Access, для новой производственной базы данных, которая будет на AWS Lightsail.Однако, когда я изменяю конфигурации подключения Ms Access, OBDC, чтобы указывать на AWS Lightsail MySQL Db, все (особенно отчеты) в интерфейсе MS Access становится медленнее, чем когда оно указывалось на MySQL Db здесь, в офисе в сети,

Я иду в «Менеджер связанных таблиц» и изменяю «Строку соединения».Где-то, что я прочитал, я должен убедиться, что SSLMODE отключен для устранения проблем с производительностью.

DSN = AWS_Dev; DATABASE = ECSDataTables; PORT = 3306; SERVER = IP_ADDRESS; SSLMODE = DISABLED;

Я прошел через обычный «Администратор источников данных ODBC» в Windows и добавил хост MySQL AWS, user / pass как обычно.

Я провел обширное исследование и нашел несколько источников, но ни один из них не являетсядействительно помогает.

Меня попросили не тратить слишком много времени на попытки исправить / оптимизировать что-либо в MS Access, поскольку я должен сосредоточиться на новом приложении, но трудно поверить, что простой переключатель базы данных MySQL может иметь такойвлияние.В новом приложении Angular / NodeJs все работает очень быстро, так что я знаю, что это не AWS MySQL db или что-либо еще.

Я что-то упускаю, какие конфигурации мне следует делать в Ms Access?Я не использовал VB около десяти лет, поэтому я надеюсь, что что-то можно сделать, не требуя слишком много технических знаний в этом вопросе.

Спасибо.

Answer 1

Ну, проблема в том, что ваша локальная сеть (ЛВС) примерно в 10 раз или более быстрее, чем ваше интернет-соединение.

Ваша недорогая офисная сеть, скорее всего, будет сетью в 1 гигабит.(100 base T - редкость).

Тем не менее, ваше высокоскоростное интернет-соединение, вероятно, скажем, 10 Мбит.Итак, вы идете с 1000 до 10 - это в 100 раз медленнее.Итак, 3 секунды теперь становятся 300 секундами.

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

Что вы можете сделать для любого отчета, представляющего собой сложное объединение клиентской части SQL, - это преобразовать SQL-запрос в представление на стороне сервера, ссылку на это представление.Теперь используйте это представление в качестве основного источника для отчета.И, конечно же, существующие VBA-файлеры, которые вы всегда используете (правильно ???) для запуска отчета, теперь будут выводить только те данные, которые ему нужны, по сетевому каналу.Доступ к отчетам (или формам) сводит только то, что вы просите, а не всю таблицуТаким образом, любой ваш фильтр (используйте условие where команды open report) будет соблюден.Таким образом, вам нужно либо извлечь меньше данных, либо просто найти что-то с такой же скоростью, что и ваша локальная сеть (а такой высокоскоростной интернет встречается редко).

Концепция и скорость локальной сети против глобальной сети описана в этой статье:

http://www.kallal.ca//Wan/Wans.html

Хотя приведенная выше статья очень старая, различия в скорости Интернетасегодня примерно в 10 раз быстрее, но так же и в локальной области, которая выросла со 100 baseT до 1 гигабитной базы.

Итак, все идет медленнее, потому что вы работаете со значительно более медленной скоростью соединения.Чем медленнее, тем медленнее !!!

Редактировать

Хотя, как уже отмечалось, доступ будет тянуть только то, что вы просите, в случае, когда клиент доступа выполняет плохую работу, это SQL-запросы, которые включают несколько таблиц - частоклиент испортит то, что он отправляет на серверную сторону.Как уже отмечалось, решением в этом случае является принятие представлений на стороне сервера.Это означает, что вы перемещаете запрос на стороне клиента, который выводит отчет в представление, и ссылаетесь на него.Вы не получаете большую производительность для одного запроса таблицы, но для любого отчета, основанного на сложных (многостоловых объединениях), тогда использование представления заставит sql и "объединить работу" происходить на стороне сервера sql, и это может привести к огромнымприрост производительности.

Answer 2

Ну, это тот случай, когда ограниченные знания приводят к худшим результатам, чем ожидаемые.
На протяжении многих лет ведущие администраторы баз данных просто "ненавидят" Ms Access ... они видят только проблемы, проблемы, которые вы называете ...последнее предложение - «переключиться на реальный движок базы данных».
Что ж, это создало ошибочное предположение, что MsSQL, MySQL, Oracle, PostGreSQL и остальные движки баз данных являются в некотором роде «волшебной пилюлей» ... вы просто переключаетеПриходите к одному из вышеупомянутых DBE, и все ваши проблемы будут решены ... просто так.
DBE - Database Engine (если вы хотите позвонить как-нибудь еще, не стесняйтесь)
НЕПРАВИЛЬНО
Ms Access следует философии, отличной от DBE, и чертовски хорошо справляется со своей задачей, учитывая все ее недостатки и основной факт, что это DBE на основе файлов.
Переключение на другое DBE дастПотрясающая производительность ЕСЛИ и ТОЛЬКО ЕСЛИ вы уважаете тот факт, что вы не работаете с Access .... просто не относитесь, например, к MySQL как к вашему хранилищу файлов, и НЕ просто связывайтетаблицы и ожидайте, что все будет хорошо ...
Хотите продолжать обвинять Access ... просто переключитесь на другую платформу (.NET, PHP, Js, Java ... сделайте свой выбор) ... и сделайтенебольшое приложение, которое тянет ВСЕ ваши данные за один раз, как вы делаете с Accessон, безусловно, рухнет или уйдет Не отвечает ...
Так что перестаньте обвинять Access ... начните читать о том, как максимально использовать два мира, и я уверен, что результаты вас поразят.... но опять же я должен подчеркнуть, что это не решение "волшебной таблетки" ... оно включает в себя МНОГО работы ... планирование, манипулирование данными, нормализация, изменения кода и, прежде всего, изменение философии ..
Я бы порекомендовал начать путешествие, выбрав эту книгу: https://www.amazon.com/Microsoft-Access-Developers-Guide-Server/dp/0672319446 (я не хочу пожаловаться на его Old и MsSQL ... просто сначала прочитайте, а потом пожалуйтесь)
Также взгляните на старуювидео, похожее на бенчмарк, которое я сделал несколько лет назад: https://www.linkedin.com/posts/tsgiannis_a-small-demo-of-connecting-ms-access-fe-to-activity-6392696633531858944-dsuU
И последнее, но не менее важное ... много лет назад я проводил несколько тестов, чтобы посмотреть, что «волшебная таблетка» сделает с приложениями моей компании ... самое простоепроверка всего ...
Простая таблица с несколькими полями, но с 8 миллионами записей ... просто отобразить ее
Доступ BE (локальный) -> Он будет запущен через 1-2 секунды ... этоfast
Access BE (общий доступ к сети) ->Он запустился бы через несколько секунд ... не так быстро, но его можно было использовать
MSSQL BE (связанная таблица) -> иногда он получал результаты, иногда это было бы не ... медленно ... очень медленно.Как будто вы делаете кофе и идете на небольшую прогулку.
MySQL BE (связанная таблица) -> он никогда не заканчивался ... тайм-аут "Не отвечает"
PostGreSQL BE (связанная таблица) -> этоникогда не заканчивается ... тайм-аут "Не отвечает"

Так что хватит обвинять Access ... начать работать и удивляться ....