Access 2007 Backend для нескольких местоположений - совместное использование с изолированной базой данных

Question

Я строю схему базы данных для двух разных штаб-квартир.Каждое местоположение использует одну и ту же схему данных, но имеет свои собственные данные.Оба будут иметь доступ к одному и тому же местоположению, общей сетевой папке, в которую будет помещен соответствующий бэкэнд доступа.Оба также будут использовать одинаковый Front-End, где в зависимости от пользователя (-account) будут показаны конкретные данные.Каждое местоположение будет иметь две основные таблицы, которые будут расти на ~ 4000-5000 записей в год.

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

По моему мнению, существует две возможности организации данных: общий подход, когда оба местоположения используют и работают с одинаковыми таблицами, где поле указывает, принадлежат ли текущие данные местоположению 1 или 2. Огромная проблема, которую я вижу, - это объем данных, который будет передан по сети (примерно вдвое), потому что (насколько я знаю) доступ выполняет операторы select локально после передачи данных. (Я исправлен).Кроме того, дополнительный запрос будет необходим для каждого доступа.

Альтернативой может быть создание второго набора таблиц для второго местоположения и их разделение (например, переименование их в loc1_tablex и / или созданиевторой backend-файл), что также упростит резервное копирование.

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

Я что-то пропустил при импорте или такой подход был бы разумным?

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

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

Answer 1

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

Тем не менее, я думаю, что здесь будет использоваться WAN, тогда я, вероятно, рассмотрю использование SQL-сервера, так как вы можете затем агрегировать данные, и это происходит на стороне сервера - будет намного быстрее, чем JET для этих типов сценариев. при условии, что вам нужны такие сценарии.

Другая возможность здесь - рассмотреть возможность использования Access 2010 и Office 365. В этом случае вы сохраняете свой обычный интерфейс Access, но перемещаете данные в Office 365.

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

Единственный недостаток при переносе данных в Office 365 - это несколько дополнительных шагов, которые необходимо выполнить, чтобы обеспечить "правильную" передачу ссылочной целостности в Office 365.

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

Прелесть этой системы в том, что она начинается за 6 долларов в месяц. И вы можете повесить много пользователей с этой учетной записи. Мало того, но такая установка также позволит вам публиковать и создавать веб-формы для ввода данных всеми, и теоретически вам даже не придется распространять формы доступа, а использовать веб-формы. затем с данными в нем. Таким образом, эти формы и данные можно просматривать на чем-то вроде смартфона или iPad, если вы это сделаете.

Вот пошаговое представление, которое показывает, как я бы разорвал связи между таблицами, а затем заново подключил их правильным образом для использования в офисе 365:

http://www.youtube.com/watch?v=3wdjYIby_b0&fmt=22&hd=1

И последнее, но не менее важное: вы можете выгружать данные с сохранением ссылочной целостности, используя Office 2010, и, следовательно, теоретически затем ссылаться на эти таблицы с помощью клиентских приложений Access 2007. Однако Access 2007 не имеет автоматического автономного режима, и производительность не будет близка к той, которую вы получаете при использовании Access 2010 с этой настройкой.

Так что я думаю, что Office 365 является потенциальным идеальным решением, поскольку вы будете получать в режиме реального времени обновления любого внешнего интерфейса в полевых условиях.

Хотя в приведенном выше видео речь шла об отправке данных и использовании обычного внешнего интерфейса Access, вы можете создавать и использовать веб-формы в Access в Office 365, как показано на этом видео:

http://www.youtube.com/watch?v=AU4mH0jPntI

Здесь не требуется activeX или silverlight.