儲存表名以引用其他表
我正在設計一個 web 應用程序，使用者可以在其中向他們的頁面添加小元件。現在我只有兩種性質不同的小元件，所以它們有不同的屬性，但它們都是用來銷售產品的。我期待將來實現其他小元件。使用者可以選擇將其中一個或兩個添加到他們的頁面中，我必須記錄使用者添加的小元件。此外，對於每個售出的產品，我必須生成並儲存金融交易的收據。因為無論它來自哪個小元件，每次銷售都是相同的，我寧願只有一個銷售表來儲存它們（而不是每個小元件類型一個表，例如：Widget1Sales、Widget2Sales 等）。而且由於可能開發了其他小元件，
到目前為止，我想出了以下設計：
因此，對於使用者添加到他/她的頁面的每個小元件，我必須進行兩個查詢：一個檢索特定的小元件表名稱，另一個（可能是動態查詢）獲取小元件資訊。產品也是如此：對於為任何給定小元件銷售的每種產品我都必須進行查詢以檢索特定的產品表名稱，然後再進行查詢以獲取產品資訊。這種安排似乎可行，但是將表名儲存在另一個表中對我來說聽起來完全是錯誤的……還有其他方法可以實現這個邏輯嗎？我已經考慮過實現某種類表繼承，但我似乎無法想像在那個特定的案例中我該如何解決這個問題。
在其他（使用者）表中儲存表名是並排儲存結構元數據和使用者數據的一個實例。這具有各種有趣的效果，其中一些效果使其對設計師具有吸引力。不利的一面不太明顯。
不利的一面是：您最終會在 SQL 中“手動”執行大量數據管理，而不同的設計可能允許 DBMS 為您執行這些操作。這使您的程式碼更難維護並且執行更慢。
話雖如此，我承認我曾多次拉過這個噱頭，而且結果通常都足夠好，以至於我沒有後悔選擇。
你的情況還有第二件事。小元件和產品的類型 1 和 2 都是類/子類建模（或者，如果您更喜歡類型/子類型建模）。這種事情在對象建模中簡單明了，因為繼承為您解決了大部分困難。在關係建模中並非如此。因此，關係建模沒有繼承機制。SQL 的某些變體具有使繼承更易於建模和實現的擴展。
在 DBA 領域有很多問題可以歸結為如何在 SQL 表中實現子類（或子類型）的問題。其中一些問題被分組在這個標籤下： subtypes。在 StackOverflow 中，這樣的問題甚至更多，並且有三個標籤與可能有幫助的三種設計技術相關：單表繼承、類表繼承和共享主鍵。
您的設計類似於類表繼承設計，只是您使用嵌入的表名而不是共享主鍵來實現子類和類之間的 IS-A 關係。您可能希望使用共享主鍵進行探索，然後通過將超類表與每個子類連接來創建收集每個子類的所有數據的視圖。我不確定你想走這條路。一旦您擁有數百種不同的產品類型，它可能會變得非常笨拙。
不知何故，我有一種印象，你在與我類似的問題上掙扎……
我建議查看您的數據庫模型。我的印像是它過度設計而不是智能關係……
widget的外鍵關係<Widget 1；widget < widget2 如果你有一個widget id x，這個id 只在widget 1 或widget 2 中，不在兩者中。另一方面，您可以在小元件 1 中創建一個指向小元件類型的附加外鍵。
或者甚至更好：如果您將 widget_type 的列包含到小元件中，則在小元件表中，您將已經擁有小元件 1 或小元件 2 的資訊，因此您會知道小元件 id_x 的類型為小元件 1 或小元件 2，其中表來尋找它。
同時，產品類型 1 和產品類型 2 非常相似。唯一的區別是產品類型 2 多了 2 個欄位，所以讓它可以為空，使用 1 個表 product_type；小元件 1 和小元件 2 也是如此，小元件 2 只比小元件 1 多一個欄位，如果繼續下去，你會突然發現，用更少的表，你可以保存相同的資訊……
小元件
id widgetType (可以是 1 或 2) widgetName widgetDescription pageID
小元件實例
id widgetID attribute1 attribute2（可為空）
產品
id 名稱 描述 價格權重（可為空） image_url（可為空） widgetInstanceID
像這樣，您將 6 個表減少到 3 個您還可以創建一個表 widgetProperties widgetInstance 1:n widgetProperties 等