動態產生的持久模型和資料儲存的設計模式

2021-06-16 01:30:06 字數 986 閱讀 3633

動態產生的持久模型和資料儲存,這個詞語感覺挺晦澀的,不過估計在實際的專案中或者研發的產品中大家都碰到過這樣的場景:

例如在乙個簡單的考試系統中,出題人在系統中出題,答題人進行相應的答題。

問題:這乙個簡單的場景對映到系統中通常會形成這樣的問題,出題人所出的題目其實就對映到了乙個題目的持久模型,而答題人進行答題時則是基於這個動態產生的持久模型進行的資料儲存,這裡的問題就是怎麼去產生這個動態的持久模型,怎麼去將資料儲存到這個持久模型裡去。

問題分析:

來看正常的情況下關於持久資料的做法,正常情況下,首先我們設計了乙個表或po,在儲存資料時則可直接將相應的資料儲存至表中。

但在現在的場景下,這個表或po需要在系統執行時產生,之後資料才能象正常的情況那樣去儲存。

解決方案:

根 據上面的問題分析,一種解決方案顯而易見,就是動態的產生表或po,這種方案應該是說難不難,說簡單也不簡單,這裡最需要注意的是產生的表的字段的屬性的 設定,以及在修改時表的字段的同步維護,如果是動態產生po的話就比較麻煩,因為按照hibernate的話,還需要生成hbm、修改 hibernate.cfg.xml,並且還需要過載sessionfactory才能生效,這種解決方案在修改持久模型時要特別注意,就是資料的保持, 很多時候採用版本策略也許更為適合。

另外一種解決方案也是經常採用的,就是不去動態的產生表或po,而是提供一種通用的資料持久策略,乙個簡單的 實現就是設計一張儲存資料的表,這張表的字段由欄位名外來鍵、字段值共同構成,欄位名外來鍵關聯到動態產生的持久模型的字段,字段值則為實際進行資料儲存時的 值,這種方案很明顯的乙個問題就是,會造成這張表的增長速度非常的塊,特別是在動態產生的持久模型中有超多字段的時候,另外乙個不是很方便的地方就是在查 詢的時候很麻煩。

在實際專案中更傾向於第一種解決方案,不過在採用hibernate之類orm的時候第一種解決方案就比較麻煩了,第二種解決方案感覺更適用於動態產生的持久模型字段比較少,實際產生的資料也比較少、查詢要求比較低的情況下。

不知道大家對於這種場景通常都會採用什麼樣的解決方案呢?

詳解Docker的持久化儲存和資料共享

有些容器會自動產生一些資料,為了不讓資料隨著container的消失而消失,保證資料的安全性。例如 資料庫容器,資料表的表會產生一些資料,如果我把container給刪除,資料就丟失。為了保證資料不丟失,這就有了volume的存在。data www.cppcns.comvolume 結構圖 dock...

訓練模型的持久化儲存

複雜的模型訓練訓練耗時太長,避免重複勞動,有必要儲存下來 這個包主要的功能 序列化物件為字串,反序列化 import pickle 儲存至本地 pickle.dump model kmeans,file open g data operation python book chapter4 model...

ARMA p,q 模型資料的產生

產生自回歸滑動平均模型 arma p,q 的資料。自回歸滑動平均模型 arma p,q 為 x n sum a x n i sum b w n i 其中 a i i 1,2,p 是自回歸係數,b i i 1,2,q 是滑動平均係數,w n 是白雜訊。給定白雜訊 w n 的均值和方差,便可以由上式產生...