通常在使用Java EE創建Model時，我們在編譯時間之前通過XML或註解來定義字段的字段和類型。有沒有辦法在運行時改變它們？或者更好的是，是否有可能在運行期間基於用戶的輸入創建新的模型？這樣的列數和字段類型是動態的（在運行時確定）？Java EE中的動態類型表/模型？
非常感謝幫助。謝謝。
我覺得有必要澄清一下自己。
是的，我的意思是數據庫建模，當談論模型。
至於用例，我想爲用戶提供一種方法來定義和創建自己的表。無限的靈活性不是必需的。然而，某種程度的自由必須在那裏：例如用戶可以定義需要哪些字段來描述他們的產品。
我在一個系統中工作，我們有這樣的設施。爲了保持高效，我們會爲客戶模式動態生成/修改表格。我們還需要嵌入一個元模型（模型的模型）來動態地在實體中處理信息。
選項1：使用自定義表格，您具有完全的靈活性，但它也顯着增加了複雜性，特別是現有數據的更新/遷移。以下是您需要考慮的事項列表：
選項2：一個輕量級的替代方法是在不同類型的業務表（例如：「USER_DATE_1」，「USER_DATE_2」等）添加一些「備用」欄目我已經看到了一個幾次。這會讓你的DBA尖叫，並不是一個好的做法，但至少可以促進一些事情，例如（遷移腳本，ORM集成）。
選項3：另一種選擇是將所有內容都存儲在具有結構屬性/數據的表中。但這對數據庫性能來說確實是一場災難。任何不完全微不足道的事情都需要很多連接。而且DBA會尖叫得更厲害。
選項4：它是選項2和3的混合。核心表是固定的，但可以使用具有屬性/數據的表以某種方式擴展它們。
總結：在你走這條路之前三思。它可以完成，但對應用程序的設計和維護有重大影響。
您聽起來像您希望能夠在運行時根據用戶輸入更改對象和模式。這聽起來像是一場混亂的食譜，對我來說是一場災難。我從來沒有見過它完成。
我已經看到了將外鍵關係合併到名稱/值對通用表的一般模式，但這些模式往往會變得無限靈活的抽象，在性能方面既不容易理解也不會走出自己的路。
我敢打賭，你的用戶真的不想要無限的靈活性。我會提醒你不要採取這個方向。最好讓你的實際使用情況一目瞭然。
當然，任何事情都是可能的。我的直接經驗告訴我，你的用戶會討厭你是否可以放棄它，這是一個壞主意。祝你好運。
同意duffymo – Xorty 2010-04-18 16:35:30
這在某種程度上可以使用元建模技術：
但這有明顯的侷限性（缺少強類型對象），恕我直言，可以很快得到非常複雜（甚至不知道如何處理關係）。我不會使用這種方法來完全定義域對象，而只是擴展現有的對象（產品，文章等）。
如果我記得不錯，這就是一些電子商務解決方案（例如BroadVision）所做的。
我想我自己找到了很好的答案。那些新的no-sql（hbase，cassandra）數據庫似乎正是我正在尋找的。謝謝大家的回答。
你是什麼意思的模型？你在談論數據庫嗎？ – Pace 2010-04-18 16:15:46
死了5年以上的J2EE，沒有註釋。但是Java EE確實如此。 – 2010-04-18 16:32:06
什麼是功能要求？基於JavaEE（或*咳嗽* J2EE）的PhpMyAdmin克隆？ – BalusC 2010-04-18 20:26:25