例如有個商品表,其中有個商品,已經跟其他表產生了關聯,像訂單表等。
但是我現在要刪除這個商品表,我是真的從資料庫中刪除嗎?
如果刪除了 其他的關聯表該怎麼處理?
如果我不刪除,資料不是一直積累在那裡?
我現在是添加了個欄位 來表示是否刪除.
你們是怎麼處理這種問題的?
回複內容:
例如有個商品表,其中有個商品,已經跟其他表產生了關聯,像訂單表等。
但是我現在要刪除這個商品表,我是真的從資料庫中刪除嗎?
如果刪除了 其他的關聯表該怎麼處理?
如果我不刪除,資料不是一直積累在那裡?
我現在是添加了個欄位 來表示是否刪除.
你們是怎麼處理這種問題的?
如果有資料依賴的話,我建議加個 status 的欄位,顯示該商品是否下線。因為訂單裡依然需要商品的詳細資料,所以不能硬刪除。
以關係型資料庫為例,我覺得可以這樣判斷,對記錄 A 進行硬刪除時,必須保證刪除與 A 相關的子集記錄,同時包含 A 資訊的記錄不會產生資料不一致。
例如,刪帖操作:
comment <-> post <-> author
刪除 post 的同時,必須要把 post 下的 comment 全部刪除,但是如果 author 的發帖記錄需要儲存的話,這時就要保證資料的一致性了。
可以採取兩種措施,第一種就是跟商品操作一樣,對 post 設定欄位標記,第二種就是根據需求生拷貝post 的標題,(所以當使用者瀏覽發帖記錄時還是能看到所有的回帖的標題,但是點擊已刪除記錄時,提示該 post 已刪除),生拷貝後的資訊可以用一張新表儲存起來,與原表相比減少了儲存空間,這個操作只是為了保證資料一致性。當將來 author 資訊也要被刪除時,等同於 comment 對 post,這個生拷貝的資訊也就可以徹底刪除了。
我認為刪除操作的痛點就在於如何保持刪除後的資料一致性問題,當然如果一開始就能設計出高範式低依賴的資料庫結構那是最好不過了。
還有一種觀點就是一切皆虛刪除,也就是整個系統沒有一次真正意義上的刪除,所有的記錄全部保留,例如 git。
把商品從product表移到archived_product表, 實現資料冷熱分離.
查詢時使用一點小技巧, 這個是 高效能mysql 的例子:
SELECT GREATEST(@found := −1, id) AS id, 'product' AS which_tbl FROM product WHERE id = 1UNION ALLSELECT id, 'archived_product' FROM archived_product WHERE id = 1 AND @found IS NULLUNION ALLSELECT 1, 'reset' FROM DUAL WHERE ( @found := NULL ) IS NOT NULL;