Лучшая практика использования глобальных настроек и настроек MS Access

Question

Я ищу лучшую практику / решение для следующего сценария.

У нас есть многопользовательская база данных ms access, которая позволяет настраивать "global_settings". Эти настройки применимы ко всем пользователям. Эти данные в настоящее время хранятся в таблице "tbl_global_settings". (у нас есть таблица user_settings для обработки отдельных вещей)

В настоящее время структура таблицы представляет собой отдельную запись с именами полей, которые представляют конкретную настройку (ужасно, я знаю). пример

tbl_global_settings.reminders_red = "7"
tbl_global_settings.reminders_yellow = "15"

Эти значения используются для условного форматирования дат истечения срока действия системных напоминаний - когда напоминание должно быть отправлено в течение 15 дней, оно будет желтым, а в течение 7 будет красным.

Когда база данных загружается, скрытая форма с именем frm_global_settings загружается со всеми полями из таблицы tbl_global_settings. Затем к ним легко получить доступ по требованию, если обратиться к полю формы.

Это работает в значительной степени идеально. Однако, поскольку эта система выросла за последние несколько лет, количество полей увеличилось (более 60), и это не кажется лучшим решением.

Я подумывал перенести это в более тонкий стол с помощью подхода Key, Parameter style. Это касается меня, хотя, поскольку использование DLookup() в MS Access, кажется, постоянно справляется со взрывом из-за неэффективности. Пример:

Key                   | Paramater
---------------------------------
reminders_red         |         7
reminders_yellow      |        14

Значения редко меняются, но часто вызываются, мне было интересно, кто-нибудь может прокомментировать, возможно ли загрузку этих данных в глобальные переменные или глобальный массив при запуске? Пример:

Public remindersRed As Integer
Public remindersYellow As Integer

remindersRed = nz(Dlookup("parameter","global_settings", "[key] = '" & "reminders_red" & "'")) 
etc.

Спасибо

Answer 1

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

Если у вас есть более 255 значений для хранения, вы всегда можете использовать более одной таблицы "глобальных настроек", возможно, в зависимости от типа настройки (например, настройки отображения, расположения папок и т. Д.). Вы можете централизовать логику поиска, создав публичную функцию для поиска указанных значений в соответствующей таблице и, возможно, даже кеширования их в объекте статического словаря, чтобы избежать повторного попадания в таблицы.

Что касается DLookup() это не является по своей сути неэффективным и будет работать просто отлично, особенно на относительно небольшом столе. (Большая часть его "плохой репутации" происходит из-за того, что он плохо используется неопытными разработчиками.)