把不常變動的資料做成json檔，存在本地，你的程式啟動時檢查檔案建立時間是否超過一個定數(我設8小時)，超過的話重新從資料庫重建一份，我在Web主機上定時建立一份全新json檔，WinForm的client端會來下載，零點幾秒的事

至於json跟C#或VB.NET的物件或陣列互相轉化，我用newtonsoft的JsonConvert.SerializeObject及DeSerialize (在nuget可免費下載)

一般做法如下

1.redis : 目前大多比較推這招。不過需要了解一下這個技術上的應用。

2.json : 將資料存成json。在做對應處理。不過這不太適合大資料。

3.緩存式 : 在資料在第一次生成就緩存到本地端。可搭配json來處理。這招算是最比較不操效能的方式。可惜的是，不適合用在有安全性的資料上。畢竟資料都會存在本地端應用。

4.本地化處理 : 不太適合網頁的做法。但一般應用可以用資源檔的方式應用。跟第3點的用法大同小異。差別是不需要跟server請求。但缺點是，如有資料變動的話。則需要更新處理。

其它其實也有搭配如orm或是共用資源的方法。這些大多是開發者額外想出的方式。跟緩存的意思有點類同。

基本上地址這一類的東西。如果是搭配3+2的應用。
我目前的做法是db跟json同時並存。

後台編輯處理是編輯db內的資料。編輯完成後，會做生成json檔的動作。
實際前端應用的程式取到的是json的資料。
且json的資料因為地址的資料很大，全放同一個json不可能。我切分區分檔記錄。
反正都是靠生成的，我也不用太擔心維護的問題。

但後台編輯則才是db的資料。

　　我覺得要先評估這些所謂【幾乎萬年不動的資料】到底有多少筆？對系統效率影響有多大來做決定，以目前電腦系統的效能來說，幾百萬筆根本不算什麼，如果能加速的有限，就不如不要花精神。

　　舉例來說，【統編＝＞公司名稱、地址】可以稱得上幾乎萬年不動，我做了一個資料庫，把全國的統編都納入，每月更新一次，總計三百多萬筆，需要撈資料時，就以統編 inner join 出公司名稱或地址，根本沒耗掉什麼時間（如下圖）。

　　所以，我認為採新技術之前，先評估一下能提昇多少差異。

我多年前的作法：

1. 資料一樣放在資料庫。
2. 每個不常異動的Table寫一個 trigger(可以是同一個stored procedure)，若 Table 有異動，會統一將最新異動時間記錄在另一個Table上，譬如 ChangeDatetime table。
3. Client端寫一個 TaskTray 程式，每隔一段時間讀取 ChangeDatetime table，如果有異動，就重新從 DB 載入至 memory。
4. Application 一律從 memory 讀取不常異動的資料。

當時，User及客戶IT部門都非常滿意。

上述流程，現在可以使用 Redis 來實現，只是要考慮大量資料時，如何做 Persistence，及開機時大量資料載入的效能問題，萬一，Redis Server 掛掉，IT 工作不會一起掛掉。

網頁的話, 可以先放到Session或ViewBag裏要用時再轉到DropDownList中, 就可調用了.
我是指ASP.NET C#的技術.