phpcms為何要將文章的”審核“狀態專門放一個表呢？

文章表news都有欄位status，為何還要另外做一個表，將處於審核狀態的文章複製到這個審核表，直接修改文章表的status欄位不是一樣的嗎？

news 12為欄位status

    1   id    mediumint(8)        UNSIGNED        2    catid    smallint(5)        UNSIGNED        3    typeid    smallint(5)        UNSIGNED        4    title    varchar(200)    utf8_general_ci            5    style    char(24)    utf8_general_ci            6    thumb    varchar(100)    utf8_general_ci            7    keywords    varchar(80)    utf8_general_ci            8    description    mediumtext    utf8_general_ci            9    posids    tinyint(1)        UNSIGNED        10    url    char(100)    utf8_general_ci            11    listorder    tinyint(3)        UNSIGNED        12    status    tinyint(2)        UNSIGNED        13    sysadd    tinyint(1)        UNSIGNED        14    islink    tinyint(1)        UNSIGNED        15    username    char(20)    utf8_general_ci            16    inputtime    int(10)        UNSIGNED        17    updatetime    int(10)        UNSIGNED    

content_check 7為欄位status

    1   checkid    char(15)    utf8_general_ci    2    catid    smallint(5)        UNSIGNED        3    siteid    smallint(5)        UNSIGNED        4    title    char(80)    utf8_general_ci            5    username    char(20)    utf8_general_ci            6    inputtime    int(10)        UNSIGNED        7    status    tinyint(1)    

回複內容：

文章表news都有欄位status，為何還要另外做一個表，將處於審核狀態的文章複製到這個審核表，直接修改文章表的status欄位不是一樣的嗎？

news 12為欄位status

    1   id    mediumint(8)        UNSIGNED        2    catid    smallint(5)        UNSIGNED        3    typeid    smallint(5)        UNSIGNED        4    title    varchar(200)    utf8_general_ci            5    style    char(24)    utf8_general_ci            6    thumb    varchar(100)    utf8_general_ci            7    keywords    varchar(80)    utf8_general_ci            8    description    mediumtext    utf8_general_ci            9    posids    tinyint(1)        UNSIGNED        10    url    char(100)    utf8_general_ci            11    listorder    tinyint(3)        UNSIGNED        12    status    tinyint(2)        UNSIGNED        13    sysadd    tinyint(1)        UNSIGNED        14    islink    tinyint(1)        UNSIGNED        15    username    char(20)    utf8_general_ci            16    inputtime    int(10)        UNSIGNED        17    updatetime    int(10)        UNSIGNED    

content_check 7為欄位status

    1   checkid    char(15)    utf8_general_ci    2    catid    smallint(5)        UNSIGNED        3    siteid    smallint(5)        UNSIGNED        4    title    char(80)    utf8_general_ci            5    username    char(20)    utf8_general_ci            6    inputtime    int(10)        UNSIGNED        7    status    tinyint(1)    

待審核文章數量肯定不大，但文章表可能有非常多的文章，甚至需要分表。

單獨看錶結構意義不大，我也沒用過phpcms，我覺得這樣可能是為了更容易對審核機制進行擴充開發。
例如，某刊物使用phpcms發布電子版，按照流程，文案要經過組長、副主編、主編三道審核，對於類似的情況下：
首先，從許可權控制上來說，分表後許可權管理就更清晰了，審核許可權不包含對原文的修改，同時避免編輯原稿汙染了受審核的資料。
其次，審核者可以在內容上批註意見，因為是內容副本，所以不影響原文。
最後，該表有獨立的status欄位，可以擴充出初審、複審、申訴等審核流程。
補充，有的cms將草稿也是獨立存放的，其實也沒有什麼特別的好與壞的問題，我覺得是和設計者的性格有關。有的人喜歡把問題集中起來，攻關之後一馬平川，有的人喜歡把問題分散開，避免複雜度的疊加減弱項目開發進度的掌控力。就像是審核表這樣，不建立單獨的表其實也能完成預定的任務，就是程式邏輯要複雜的多而已。

