Редактировать. Мне сказали, что мой вопрос слишком широк и может привести к ответам, основанным на мнении.Я не согласен, но в любом случае, пытаясь принять этот вопрос как действительный, вот краткий обзор:
Возможно ли иметь разделенную базу данных MS Access, где некоторые из таблиц физически являются общими для нескольких серверных частей??Под физически распространенным я подразумеваю, что некоторые физические таблицы являются общими.Это позволило бы администраторам обновлять поля в относительно стабильных данных таблицах в одном внутреннем экземпляре, чтобы обновления просматривались во всех внутренних экземплярах.В то же время большинство внутренних таблиц остаются отдельными, поэтому изменения в этих данных будут применяться только к этому конкретному внутреннему экземпляру.
Правка заканчивается
Я собираюсь попытаться разделить базу данных Access для разработки, и я уверен, что это будет простой процесс.Однако в дальнейшем я хотел бы реализовать разделение со ссылками между некоторыми из внутренних таблиц или даже с тем, чтобы некоторые из внутренних таблиц были общими.Я попытался найти информацию о жизнеспособности этого, но пока все, что я могу найти, - это помощь по перенаправлению внешнего интерфейса к различным внутренним данным и помощь по созданию различных внешних интерфейсов для просмотра автономных внутренних данных.
Мой будущий сценарий таков:
Я хочу несколько разных наборов внутренних данных;один полный общенациональный набор, другие ограничены данными, импортированными из источника A, источника B и т. д. Все это будут параметры производственных данных, доступные пользователю, и структура будет идентична для всех из них.Хотя таблица и структура запросов идентичны, способ представления данных в некоторых полях формы / отчета отличается от одного источника к другому, и любая попытка представить данные из всех источников вместе может запутать пользователей.Я думал о переводе различных представлений в общий формат, но это потеряло бы некоторые детали информации.
Я также хочу рабочий интерфейс плюс хотя бы один интерфейс разработки / тестирования.Первый должен позволять пользователю подключаться к любому из внутренних наборов производственных данных, а внешние интерфейсы dev / test должны разрешать присоединение к чему-либо, с тем ограничением, что любой внешний интерфейс dev должен соответствовать структуре совпадающего внутреннего интерфейса dev.Вполне возможно, что потребуется несколько пар девайс-фронт-энд-бэкэнд в зависимости от одновременных структурных испытаний.Опять же, хотя это может потребовать тщательного контроля версий, я вполне уверен, что он будет работать достаточно легко.
Итак, моя проблема: я бы хотел, чтобы некоторые из внутренних физических таблиц были разделены между всемипроизводственные фоновые наборы данных.Это связано с тем, что некоторые таблицы очень структурно стабильны, и их данные будут общими для всех рабочих версий и изменяться только пользователями с правами администратора.Я хочу позволить пользователям-администраторам изменять / добавлять / удалять данные в этих стабильных производственных таблицах только один раз, чтобы их обновления были доступны всем рабочим серверам.В худшем случае пользователям с правами администратора придется вносить такие поправки в каждый из наборов внутренних данных, что, очевидно, создает вероятность несоответствия между различными наборами внутренних данных - кто угодно кофе?Теперь, где я был?
Полагаю, я мог бы написать что-то для обновления данных во всех внутренних таблицах, но это не идеально, хотя и не в худшем случае.
Я мог бы добавить к некоторым изтаблицы представляют собой поле «набор данных» и расширяют мои формы, запросы, отчеты и т. д., чтобы принять во внимание набор данных, таким образом, имея только один набор производственных данных, но который кажется дешевым и не очень надежным;более того, это, вероятно, ухудшит производительность.
Есть ли какой-либо способ, учитывая обстоятельства, которые я описал выше, что я могу иметь данные бэкэнда совместно для нескольких физических таблиц?Не все, только несколько из них?
Надеюсь, я достаточно хорошо описал проблему (возможно, слишком подробно), чтобы кто-то, у кого была эта проблема в прошлом, может указать мне на решение.