#database #ms-access #split
#База данных #ms-access #разделил
Вопрос:
Полагаю, я правильно понимаю, что разделение базы данных предполагает, что все таблицы будут находиться на серверной части, а все остальное — на интерфейсной.
Вот моя проблема. Я работаю в крупной компании, и люди по всей стране используют базу данных. Около 60 — 65 человек. Обычно не более 4 или 5 синхронно, хотя.
У меня есть одна статическая таблица, которую я использую в качестве справочной таблицы в форме, которая загружает основную таблицу. Если у меня есть эта статическая таблица в BE, время загрузки формы для некоторых пользователей, в зависимости от их удаленности от сервера, может составлять более двух минут. Если я помещу эту статическую таблицу в FE, время загрузки увеличится в 4-5 раз.
Мой вопрос; может ли наличие статической таблицы вызвать какие-либо другие негативные проблемы с моей базой данных, или просто «рекомендуется», чтобы все таблицы были в BE? Мой мыслительный процесс заключается в том, что, поскольку я получаю такое огромное увеличение производительности при использовании FE, что если мне нужно изменить эту статическую таблицу, я просто распространю новый FE. Это разумная логика?
Ответ №1:
Конечно, да. Если это просто статическая таблица поиска, и ее загрузка из серверной части каждый раз занимала бы слишком много времени, то вполне нормально поместить ее во внешний интерфейс.
Если вы не хотите распространять новый интерфейс при каждом изменении таблицы, вы могли бы поместить таблицу в серверную часть, и каждый интерфейс импортировал таблицу при запуске:
'run this in the frontend on startup
DoCmd.DeleteObject acTable, "Your_Table"
DoCmd.TransferDatabase acImport, "ODBC", ";DATABASE=c:backend.mdb", acTable, "Your_Table", "Your_Table", False
(конечно, вам придется соответствующим образом изменить имя вашей таблицы и путь к серверной части)
Комментарии:
1. 1 за предложение по импорту при запуске, но если загрузка формы, извлекающей данные, занимает более 2 минут, запуск импорта во внешний интерфейс может серьезно замедлить время запуска.
2. Я почти ожидал, что кто-нибудь скажет что-то вроде этого. Ну, это зависит 🙂 Мы не знаем, как именно таблица используется в основной форме, загрузка которой занимает две минуты, когда таблица находится в серверной части. Возможно, импорт всей таблицы по сети проходит быстрее, чем выполнение некоторых запросов к ней — кто знает. И если таблица часто меняется, возможно, он сможет выдержать более длительное время запуска, если ему не придется так часто распространять новые интерфейсы. Все зависит…
3. Отлично, спасибо за отзыв, и мне действительно нравится идея импортировать поиск при запуске. Это небольшая таблица, но форма, которая ее использует, содержит некоторый код, и, поскольку она связана, это замедляет ее работу. Отличная идея … спасибо!
4. @Дреннен Гаффни: Если вам нравится мой ответ, вы можете выразить это, приняв его 🙂
Ответ №2:
Ваша статическая таблица может находиться во внешнем интерфейсе. Вы также должны включить в FE каждую таблицу, которая не изменяется и которая является частью «выпуска», например: таблица меню панели мониторинга.
В любом случае, если у вас есть такие «перемещающиеся» пользователи, я бы серьезно подумал о переносе данных на SQL Server, что действительно может уменьшить сетевой трафик и повысить производительность.
Ответ №3:
Я бы сделал статическую таблицу в FE. Теперь я делаю это с таблицами, которые строго ограничены пользователями и которые не нужно сохранять в базе данных BE. Затем, если вам нужно добавить новые данные, просто опубликуйте новый FE для своих пользователей.
Я думаю, что это упрощает обслуживание BE, потому что тогда у вас нет статических / ненужных таблиц, содержащихся в BE. Я сделал это со своей, некоторые статические таблицы отправились в базу данных FE, а некоторые — в базу данных SQL server.
Это действительно зависит от того, что, по вашему мнению, будет проще для ваших пользователей, а также для вашего обслуживания.