什麼是可以「被丟棄」的對象的合適的桌子設計

Question

我正在設計一個簡單的媒體「服務器」作爲更大的應用程序的一部分。我選擇採用與AWS S3服務類似的術語，即Objects和Buckets（即文件和目錄）。

我有兩個表：

cdn_bucket 
id, directory 

和

cdn_object 
id, bucket_id, filename, is_deleted 

數據庫中的其他表可以使用上cdn_object.id外鍵包含的對象。這有很好的副作用，因爲我可以指定一個約束來在刪除對象的情況下設置字段NULL（或者實際上防止刪除，如果需要的話）。 e.g：

blog_post 
id, title, body, featured_image 
CONSTRAINT: featured_image = cdn_object.id ON DELETE SET NULL 

有人告訴我，一旦我不應該刪除的東西，永遠（這是另一篇文章的說法，請不要在這裏發表評論）;因此is_deleted標誌。爲了澄清這個問題，這就是我所說的「被濫用」，即可以恢復的意思。

這很好，但是我不能利用約束的級聯功能（即我將一個對象標記爲已刪除，但引用表，例如blog_post.featured_image引用舊的ID）。

我想知道SO的意見可能會對以下兩種方法產生什麼影響，或者如果有另一種方法可能會更好。

1.加入cdn_object表

SELECT bp.*, cdno.id featured_image FROM blog_post bp JOIN cdn_object cdno ON cdno.id = bp.featured_image AND cdno.is_deleted = 0。

專業：易於實施。

Con：每個查詢都必須加入cdn_object表。

或

2.使用垃圾表

有另一個表，cdn_object_trash，並讓代碼「搬家」的行cdn_object當它刪除，引發所有級聯約束。

臨：允許關係規則做他們的目的是做

缺點：不好的設計？不確定。

我的直覺告訴我，我應該使用is_deleted標誌並編寫相應的代碼，但是這是一個通用類，所以我寧願不強迫開發者編寫的參加每一次，如果我可以配置數據庫中的邏輯。

我希望我的情況/問題很明確，如有需要，請讓我澄清任何問題。

Answer 1

您的第三個選擇是設置合理的備份和保留計劃，並使用級聯刪除。雖然我理解「不要刪除任何東西」的願望，但遵守這一原則會迫使您在編程選擇（選項1）中多餘，或者想出如何構建垃圾表來冗餘地存儲信息（選項2;您是否用數據的字符串表示構建單個表，還是製作模式的垃圾副本？）。這兩種選擇似乎都需要很多工作來維持（長期以來）。

我已經使用了兩種選擇的變體，並且如果這些是表格上的唯一選項，則選項1更容易維護;但是，您必須非常勤奮地使用它，並且您必須確保未來的開發工作符合相同的標準。