一般的CMS或者CMF都應該有模型這一塊。現在我就onethink這個CMF來談一下我的想法，由於我剛接觸Onethink，所以可能理解不到他的精髓，希望大家批評指導，交流下。
onethink採用的是，所有資訊都壓在一個表裡面，就是那個預設的文件模型，大家可以根據基礎模型來擴充套件自己的需求。當然這樣做的好處是方便全站搜尋，但也無形中給這個文件表太大的壓力，如果資料量比較大，這個表是扛不住的。
還有一種方法是分表，也正是我想採用的方法。
資料庫一個model表，新建的模型就寫入這個表，一個欄位表fields，所有的欄位資訊都寫入這個表，用模型ID來標示屬於哪一個模型。
使用者新建一個模型，就生成一個新表。
然後後臺建立分類的時候，關聯具體的模型。然後當你點選具體分類發飆資訊的時候，彈出的表單就自動呼叫關聯模型下面的所有欄位。根據欄位型別來生成表單。發表的資訊當然就寫入模型對應的表中。
這樣感覺挺方便的，各個分類下面的表單都可以靈活控制。
也不會因為資料量很大帶來壓力。
其實這裡面我談的模型，他的主要作用就是新建資料表，自定義表的欄位。從而實現表單的靈活性，也是分表的一個方法。
關於欄位驗證之類的，可以在模型上擴充套件
當然，這樣做同樣也會帶來問題，比如，如果做全站搜尋的時候會較麻煩，需要用到分詞或其他外掛來解決。
有這樣的想法主要是覺得，ONETHINK的模型這塊搞的比較混亂。或者說太高階了，沒搞懂獨立模型、文件模型。新建獨立模型不能跟新建的分類關聯。有點暈。
我只是想跟大家探討下，不是亂噴，請大家賜教，說下自己的想法。
onethink採用的是，所有資訊都壓在一個表裡面，就是那個預設的文件模型，大家可以根據基礎模型來擴充套件自己的需求。當然這樣做的好處是方便全站搜尋，但也無形中給這個文件表太大的壓力，如果資料量比較大，這個表是扛不住的。
還有一種方法是分表，也正是我想採用的方法。
資料庫一個model表，新建的模型就寫入這個表，一個欄位表fields，所有的欄位資訊都寫入這個表，用模型ID來標示屬於哪一個模型。
使用者新建一個模型，就生成一個新表。
然後後臺建立分類的時候，關聯具體的模型。然後當你點選具體分類發飆資訊的時候，彈出的表單就自動呼叫關聯模型下面的所有欄位。根據欄位型別來生成表單。發表的資訊當然就寫入模型對應的表中。
這樣感覺挺方便的，各個分類下面的表單都可以靈活控制。
也不會因為資料量很大帶來壓力。
其實這裡面我談的模型，他的主要作用就是新建資料表，自定義表的欄位。從而實現表單的靈活性，也是分表的一個方法。
關於欄位驗證之類的，可以在模型上擴充套件
當然，這樣做同樣也會帶來問題，比如，如果做全站搜尋的時候會較麻煩，需要用到分詞或其他外掛來解決。
有這樣的想法主要是覺得，ONETHINK的模型這塊搞的比較混亂。或者說太高階了，沒搞懂獨立模型、文件模型。新建獨立模型不能跟新建的分類關聯。有點暈。
我只是想跟大家探討下，不是亂噴，請大家賜教，說下自己的想法。
回覆
你好，再見
評論
高手，再見，請問你做的網站一般有多大的文章數量
評論
onethink 內容那塊文件模型採用的是繼承方式即一條記錄分散在兩張表裡,所有內容相關的模型都要從文件模型基礎,獨立模型就上不從文件模型基礎,是一個獨立的表.官方文件說的很清楚,這樣做的好處是,便於管理,能實現各種獨立模型不能實現或者實現很困難的操作,比如文件移動和合並等,而且便於全站檢索。缺點就是你提到的所有文件模型及其繼承者的資料記錄都集中在一個表裡.壓力很大, 但到底文件數量到了什麼數量級對效能造成多大的影響,這個可能要專門去驗證下
評論
下意識看了下發帖時間