Разделить базу данных Access на отдельные данные и файлы интерфейса?

Question

Я видел, как это было сделано однажды, но не понимал, почему строитель сделал это.В чем преимущество, и если оно есть, то почему в литературе нет примеров такой архитектуры?

Я просто ищу подход с наилучшей практикой для небольшого офиса около 10 или около того.пользователи, прежде чем я начну (офис, который хочет специально перейти на БД Access).

Спасибо.

Answer 1

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

Производительность улучшена. Сетевой трафик ограничен. При необходимости можно сохранить уникальные копии временных / кэшированных данных. Резервные копии на данных немного меньше. Не всем пользователям требуются одинаковые функции, поэтому разные приложения могут использовать одни и те же данные. Менеджеру, которому нужно всего несколько отчетов, не нужен файл с 50 формами.

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

Answer 2

Ах, вы имеете в виду два разных файла Access, один только с системным интерфейсом, а другой с базой данных, верно?

Если это так, ответ довольно прост.

Подобные действия обеспечат средства для обновления интерфейса без простоя системы и могут помочь в резервном копировании данных.

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

Однако для сценария, который вы рисуете, я бы обновил его до SQL Server Express и фактическогопрограммное обеспечение, разработанное для компании.