在招聘應用程序中，我有一個模型'工作'允許用戶創建項目符號列表，更復雜的數據對象
管理員能夠創建新的工作。
作爲該工作描述的一部分，它將有大約4-5個項目符號彙總它。
它也將具有作業中的所有角色以及它的描述。
這些只是爲了創建用於顯示的目的，不是爲了過濾等
這裏有我有，雖然這個問題，你將如何讓用戶創建這些項目符號列表，和角色？
我可以像
bullet_list_1:string
bullet_list_2:string
role_1_title:string
role_1_dsc:string
etc...
在軌創建數據。但是，如果我這樣做，這樣，然後在特定的工作崗位可能會有更多的要點，以及其他工作少要點。
你會如何處理這種情況？
我在想一個has_many的關係可能會這樣做，但如果有更好的解決方案，一切都會好起來的！
我根據您的問題特點的結論：
技術候選人：
ActiveRecord的關係（的has_many）
這將被過濾掉。由於領域不確定，因此無法應用該方法。通過降價
文本解析這將填補基本需求。您還可以顯示每個字段的創建形式，並在保存時將它們組合爲降價。但是，對於編輯而言，編輯原始降價更容易，而不是將其轉換回創建等形式。另外，當你想定製視圖輸出時，它會變得不那麼靈活，比如說顯示其中的一部分。
文檔數據庫MongoDB的一樣
這將是一個完美的結合。所有項目符號和其他信息都可以保存在一個鍵/值對中。關於文件
如果使用的PostgreSQL
ActiveRecord的替代方法，可以考慮hstore（對於一個水平的鍵/值）或json（對嵌套級的鍵/值）數據字段。如果不是PostgreSQL，您可以使用文本字段並將其序列化爲散列或JSON，但性能較差。
結論：
如果 「作業」 模式是核心業務，我會考慮的MongoDB。如果還有其他限制，我會考慮PostgreSQL hstore或JSON，最後是序列化文本字段。