Что ж, доступ к связанным таблицам в SharePoint ВСЕГДА использует локальную копию рассматриваемых данных.
Вы можете проверить «очистить» кеш при выходе, но по соображениям производительности я не советую вам делать это.
Итак, что делает доступ, «первым» выполняет «синхронизацию» с локальной копией данных (имейте в виду, что в этом контексте я НЕ говорю о локальных таблицах доступа - но связанных таблицах ТОЛЬКО в этом контексте).
Это означает, что SQL-запрос фактически обрабатывается локально и выполняется ТОЛЬКО проверка обновлений и «синхронизации» локальной таблицы.
До Access 2010 (и SharePoint 2010).), тогда этот «локальный» кэш был необработанным xml, и он был ОЧЕНЬ медленным.
Теперь для такого SQL используется механизм локальной базы данных.Однако высокоскоростная локальная индексация работает ТОЛЬКО для столбца PK - другие столбцы (к сожалению) не проиндексированы.Однако, поскольку локальная обработка и производительность оперативной памяти «глупы» быстро, это работает довольно хорошо для таблиц до 50 000 записей.
Если вы выполняете соединение между этой связанной + «кэшированной» таблицей и локальной таблицей доступа?Хорошо, если вы присоединяетесь к столбцу PK связанной таблицы, то эта обработка происходит «локально».Однако, если вы присоединяетесь к чему-либо, кроме PK, тогда у вас нет индексации - это приведет к потере локальных ресурсов процессора и оперативной памяти - такие запросы работают не так хорошо.
Так что, как правило, любойSQL, который вы используете для «попадания» в связанную таблицу, фактически «запускается» локально по отношению к локальной кэшированной таблице.Если эта локальная связанная таблица НЕ имеет полного кэша данных, выполняется запрос в SharePoint.Извлечение данных в этом случае может и будет ограничено вашим фильтром, но данные SharePoint - это списки данных в формате XML, а не таблица строк и столбцов, подобных SQL-серверу.SharePoint выполняет «приличную» работу по обработке таких запросов, но имейте в виду, что SQL не обрабатывается на стороне сервера (он конвертируется в синтаксис верблюда, и это «веб-служба», а не ODBC или тип базы данных)тянуть).
И да, данные загружаются и обрабатываются локально.Однако, как отмечалось, Access «сохраняет» этот кэш данных локально.Таким образом, теоретически вы можете запросить таблицу из 20 000 строк, и ОЧЕНЬ мало, если будет происходить сетевой трафик в SharePoint (только проверка / проверка для синхронизации таблицы).Если не происходит никаких изменений в таблице, такой запрос выполняется «в основном» локально по отношению к локальному кешу таблиц.
Имейте в виду, это означает, что такой запрос может выполняться довольно быстро, но обновления для больших таблиц будут все еще выполняться медленнокак черепаха, потому что для каждого локального обновления строки должна произойти «синхронизация» этих данных с SharePoint.И вы не можете запускать / использовать обновления на стороне сервера, как, например, с помощью сервера SQL.Причина здесь проста: если вы попытаетесь запустить сервер обновлений, то синхронизация каждой строки произойдет вплоть до клиента - и вы ПОСТОЯННО получите огромный сетевой штраф.
Так что в некоторых случаяхтакие SQL-запросы к SharePoint будут проходить вокруг SQL-сервера.(Поскольку локальный кеш таблицы может быть использован).А поскольку связь между Access и SharePoint является «веб-службой», то технологический стек разработан вокруг концепции сети, которая позволяет «часто» делать небольшие разрывы в соединении.Фактически, если ваше соединение потеряно на 100%, Access будет продолжать работать с локальными данными до тех пор, пока вы не восстановите подключение к Интернету, и в SharePoint может произойти «синхронизация» данных локальной таблицы.Таким образом, эта настройка допускает режим «off-line» - Access может работать с разорванным соединением.
Если вы используете ODBC для SQL-сервера, то «любой» небольшой разрыв в интернет-соединении разорвет соединение, и выобычно приходится выходить + перезапускать Access.Таким образом, с точки зрения «интернета», технологический стек, используемый в SharePoint, намного лучше, чем SQL-сервер.
Однако большая проблема заключается в том, что списки SharePoint плохо масштабируются для приложений с большим количеством строк илиприложения с множеством обновлений строк.
Также имейте в виду, что все отношения между таблицами в SharePoint должны иметь pk ID (номер), а FK также должен быть числом.Таким образом, поддерживается каскадное обновление и каскадное удаление между таблицами SharePoint, а также Access.
Так что, как правило, я бы ограничил размеры таблиц, скажем, 10 000 строк, возможно, 15 000 вершин.И имейте в виду, что если вы используете Office 365, то наборы данных запросов ограничиваются 5000 строками.Если вы используете локальный SharePoint, то все эти «ограничения» и ограничения можно отключить.
Так что приложения, которые обновляют большое количество строк за один снимок, плохо работают с Access to SharePoint.И приложения с большим количеством строк и большим количеством реляционных объединений также плохо масштабируются.Имейте в виду, что есть два типа масштабирования, о которых я здесь говорю.В этом случае мы говорим о большом количестве строк, а не о «горизонтальном» масштабировании с большим количеством пользователей.SharePoint (и Access) могут обрабатывать довольно большое количество пользователей, но большое количество строк данных - это другой вопрос и история.
Таким образом, на самом деле никакой sql не обрабатывается на стороне сервера, поскольку SharePoint не обновляет строки с помощью механизма SQL- это система обновлений на основе веб-службы.
На самом деле все сводится к тому, насколько большими будут наборы строк.Для приложений, ожидающих менее 10000 строк, у вас должно быть все в порядке.Если вы ожидаете большего числа строк, то я предлагаю вам использовать SQL-сервер для серверной части или даже SQL Azure, если вы хотите облачное решение.
edit: Кроме того, чтобы получить приемлемую производительность, вам нужен Access 2010или позже, а также sharePoint 2010 или позже.Необходимо убедиться, что вы отметили эту опцию, чтобы локальный кеш работал: 