邏輯結構相同的表是否應該合成一張表?

在新公司做項目的時候, 遇到的技術領導要求將邏輯結構相同的表全部合成一張表.
例如:

comment #評論表    id    user_id    content    reply_id    add_timemessage #私信表    id    user_id    reply_user_id    content    reply_id    add_time

兩張表結構相同, 然後領導讓結構相同的表合并, 再加一個type進行處理, 這樣可以減少相同的代碼. 我覺得這樣不太好, 萬一之後增加功能就會比較頭痛, 如果是為了減少代碼的話, 兩張相同結構表的model繼承同一個model也就可以了, 不至於要把功能不同的表合并成一張吧, 以後如果為了節約效能, 不是還得拆表?

大家是怎樣認為的呢?

回複內容：

在新公司做項目的時候, 遇到的技術領導要求將邏輯結構相同的表全部合成一張表.
例如:

comment #評論表    id    user_id    content    reply_id    add_timemessage #私信表    id    user_id    reply_user_id    content    reply_id    add_time

兩張表結構相同, 然後領導讓結構相同的表合并, 再加一個type進行處理, 這樣可以減少相同的代碼. 我覺得這樣不太好, 萬一之後增加功能就會比較頭痛, 如果是為了減少代碼的話, 兩張相同結構表的model繼承同一個model也就可以了, 不至於要把功能不同的表合并成一張吧, 以後如果為了節約效能, 不是還得拆表?

大家是怎樣認為的呢?

我認為所有有關資料庫設計的問題，都要從「查詢」這個角度來考慮。即你要預計一下你今後會如何查詢這個表，再考慮如何設計結構。

回到問題，你可以考慮一下：

• 評論是否總是和私信一起查詢
• 是否有必要在尋找私信的時候尋找一遍評論
• 評論和私信的 ID 是否有必要使用同一個序列

樓主可以反過來思考，拆表。
一些訪問量比較大的站，日誌標題和描述是一個表，日誌內容是一個表
因為別人訪問日誌列表的時候不一定要看到日誌內容，多的日誌查詢就會造成一種浪費
表的合并，我認為主要是看他們在查詢時，是否需要經常一起顯示，如果僅僅是為了減少代碼量，這個完全沒有必要吧，隨著以後系統使用者評論內容和私信內容的增加，勢必會影響到效率

資料庫的表，一般情況下代表一個業務對象，如果兩個業務對象屬於同一類型，只是分不同類型有個別不同的欄位，可以考慮公用一張表，然後用一個type欄位進行區分。

樓主的例子裡面，評論和私信顯然不是一個業務對象，表裡面的content，reply_id雖然名稱相同，但代表的業務含義完全不同，所以建議分成兩張表。否則後期維護的時候非常麻煩，營運的人剛開始肯定不理解，為什麼同一個欄位，在資料庫裡面根據另外另外一個type欄位有不同的含義。

