SQL表中的通用ID列是一個壞主意嗎？

Question

在我們的數據庫中，我們有許多帶有“注釋”列的表。 這是重要的功能，但是對於大多數行，Notes的值為null。 這些表有很多列，我們希望刪除一些列以提高可讀性。

我們可以為每個具有notes列的表添加一個Notes表。 但這會造成另一種混亂—太多的小桌子。

我的想法是創建一個通用的Notes表和一個參考表。 Notes表將具有用於注釋文本的列，用於鏈接至該行的ID的列以及指向參考表的外鍵。 對於每個需要我們注意的表，參考表都有一個文本值。 使用這兩個表，我們應該能夠將注釋鏈接回它來自哪個表和列。

通過使用此解決方案，我們從便箋中刪除了所有空值的情況，並精簡了一些表。 全部以兩張額外桌子的適中價格出售。 但是，對我來說，這感覺很“ hacky”。 從數據庫管理的角度來看，使用“通用” id列或其他表的引用表是一個不好的主意嗎？

Answer 1

在SQL Server中，管理對完全不同的實體的引用可能確實具有挑戰性。 相比之下，Postgres支持繼承，這使繼承更加簡單。

因此，我的建議是向要注釋的每個實體添加一個notes列。 如果需要所有筆記的視圖，則可以添加視圖以將所有筆記放在一起。

這對性能或數據大小的影響最小。 除了額外的NULL位之外，對於varchar列沒有任何額外的開銷-這是非常小的。

Answer 2

IMO，另一個管理兩個表的解決方案效率不高，但是增加了解決方案的復雜性。 您可能應該堅持使用數據類型為varchar的原始表中的notes列。

通用id列從本質上來說還不錯，但是使用它通常會讓人聞到不好/過時的設計。

Answer 3

對於SQL Server，您還可以在注釋列中使用稀疏來減小大小。 但是我本人也使用類似的方法。 （請注意，許多列都需要寫信息/ changerequest / lockcomment的列。但通常不會使用）。 工作正常，可以在源代碼中進行通用編程。 但是，如果每張表只需要一個注釋列，我會選擇稀疏