動態產生的持久模型和數據存儲，這個詞語感覺挺晦澀的，不過估計在實際的項目中或者研發的產品中大家都碰到過這樣的場景：
例如在一個簡單的考試系統中，出題人在系統中出題，答題人進行相應的答題。
問題：
這一個簡單的場景映射到系統中通常會形成這樣的問題，出題人所出的題目其實就映射到了一個題目的持久模型，而答題人進行答題時則是基于這個動態產生的持久模型進行的數據存儲，這里的問題就是怎么去產生這個動態的持久模型，怎么去將數據存儲到這個持久模型里去。
問題分析：
來看正常的情況下關于持久數據的做法，正常情況下，首先我們設計了一個表或PO，在保存數據時則可直接將相應的數據保存至表中。
但在現在的場景下，這個表或PO需要在系統運行時產生，之后數據才能象正常的情況那樣去保存。
解決方案：
根據上面的問題分析，一種解決方案顯而易見，就是動態的產生表或PO，這種方案應該是說難不難，說簡單也不簡單，這里最需要注意的是產生的表的字段的屬性的設置，以及在修改時表的字段的同步維護，如果是動態產生PO的話就比較麻煩，因為按照hibernate的話，還需要生成hbm、修改hibernate.cfg.xml，并且還需要重載SessionFactory才能生效，這種解決方案在修改持久模型時要特別注意，就是數據的保持，很多時候采用版本策略也許更為適合。
另外一種解決方案也是經常采用的，就是不去動態的產生表或PO，而是提供一種通用的數據持久策略，一個簡單的實現就是設計一張存儲數據的表，這張表的字段由字段名外鍵、字段值共同構成，字段名外鍵關聯到動態產生的持久模型的字段，字段值則為實際進行數據存儲時的值，這種方案很明顯的一個問題就是，會造成這張表的增長速度非常的塊，特別是在動態產生的持久模型中有超多字段的時候，另外一個不是很方便的地方就是在查詢的時候很麻煩。
在實際項目中更傾向于第一種解決方案，不過在采用Hibernate之類ORM的時候第一種解決方案就比較麻煩了，第二種解決方案感覺更適用于動態產生的持久模型字段比較少，實際產生的數據也比較少、查詢要求比較低的情況下。
?
不知道大家對于這種場景通常都會采用什么樣的解決方案呢？
ps：還有一個場景感覺也是常見的，就是需要動態的擴展目前已有的PO或表，不知道在這個場景中大家會采用什么樣的解決方案，預留字段？動態修改表？關聯屬性擴展表？抑或別的..........