2

次のシナリオのベスト プラクティス/ソリューションを探しています。

「global_settings」の構成を可能にするマルチユーザー ms アクセス データベースがあります。これらの設定は、すべてのユーザーに適用されます。このデータは現在、テーブル 'tbl_global_settings' に保存されています。(個々のものを処理するためのテーブル user_settings があります)

現在、テーブルの構造は、特定の設定を表すフィールド名を持つ単一のレコードです (ひどい、私は知っています)。例

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

これらの値は、システム リマインダーの条件付き書式の有効期限に使用されます。リマインダーの期限が 15 日以内の場合は黄色になり、期限が 7 日以内の場合は赤色になります。

データベースがロードされると、テーブル tbl_global_settings のすべてのフィールドを含む frm_global_settings という隠しフォームがロードされます。これらは、フォーム フィールドを参照することにより、必要に応じて簡単にアクセスできます。

これはほぼ完璧に機能します。しかし、このシステムがここ数年で成長するにつれて、フィールドの数が増え (60 以上)、これは最善の解決策とは思えません。

これを、キー、パラメーター スタイルのアプローチを使用して、よりスキニーなテーブルに移動することを検討していました。ただし、MS Access で DLookup() を使用すると、非効率性が絶えず爆発するように思われるため、これは私にとって懸念事項です。例：

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.

ありがとうございました

4

1 に答える 1

4

あなたの現在のアプローチ（1行、多くの列）は「ひどい」ものではありません。列の数が増えると少し扱いに​​くくなりますが、格納する値が 255 を超えるまでは問題なく動作します (Access テーブルの列数の制限)。また、各列に特定のタイプがあり、それに関連付けられた検証ルールを設定できるという利点もあります。

保存する値が 255 を超える場合は、おそらく設定の種類 (表示設定、フォルダの場所など) に基づいて、常に複数の「グローバル設定」テーブルを使用できます。パブリック関数を作成して適切なテーブルで指定された値を検索し、場合によってはそれらを静的辞書オブジェクトにキャッシュして、テーブルに繰り返しアクセスすることを避けることで、検索ロジックを一元化できます。

それDLookup()は本質的に非効率的ではなく、特に比較的小さなテーブルでは問題なく機能します。(その「評判の悪さ」の多くは、経験の浅い開発者があまり使用していないことに起因しています。)

于 2015-01-15T10:42:56.320 に答える