在sql中哪一個是正確和優化的？

想像一下，我有三個實體 ( EntityA, EntityB, EntityC) 可以有一些images. 所以有兩種方法：

1. image為每個實體製作一個表格。這意味著它EntityA有一個image名為 and 的表，與和AImages類似。這種方法更智能，但表格更多。EntityB``EntityC
2. 有一個image表和另一個表名EntityType。

EntityType表有一個EntityTypeId列和一個name，並有三個記錄：1,EntityA, 2,EntityB, 3,EntityC。

然後在image表中：

EntityA如果我為表中的記錄保存記錄image將是這樣的：1,1,name

第一列是ImageId，第二列是，EntityTypeId第三列是image's filename。

EntityB如果我為表中的記錄保存記錄image將是這樣的：2,2,name

如果我為表中EntityA的記錄保存一條記錄，image將是這樣的：3,3,name

在這種方法中，表的數量會減少，但查詢會更長。

哪個是優化的或任何其他方式…

不要擔心數據庫中的表數量。SQL 伺服器每個 DB可以處理數十億個對象。儘管如果存在大量對象，理論上會有性能成本，但與設計不良的表上編寫糟糕、索引錯誤的查詢相比，這將是微不足道的。

在數據庫中保存數據只是故事的一部分。另一個更重要的部分是再次將其取出。仔細考慮您的案例。您將向架構送出哪些查詢？你能有效地索引來處理每一個嗎？你能寫出簡單、清晰的 SQL，在凌晨 3 點有人可以理解和修復，而以前從未見過你的程式碼嗎？

因此，對於實際問題，我會選擇三個單獨的表格。首先，它是一個更清潔的設計。 ImageA涉及EntityA; 每個人都可以理解發生了什麼。僅僅因為兩個表具有相同的列並不一定意味著它們是相同的。其次，對於組合表，您不能對其施加外鍵約束，ImageID因為它可能引用三個表中的任何一個。（從您的範例中不清楚，但我假設您計劃在每個 ID 中使用一個 ID 列EntityA, B and C，並且相應值具有相同的ImageID值。）第三，您將如何索引它？集群EntityTypeID，可能是三個過濾索引，甚至可能分區EntityTypeID? 砰！你又得到了三個表，只是隱藏在一個額外的間接層下。最後，如果一個實體可以有多個圖像設計 2 將要求名稱位於主鍵中，這會使索引效率低下。

對您的 BA 提出的另一個問題 - 根據您的應用程序使用者社區的理解，各種圖像是否相同？在系統之外，在現實世界中，它們是否以幾乎相同的方式創建、處理、存檔和銷毀三類圖像。例如，如果我們談論 X 射線照片，它們可能是醫學 X 射線 ( EntityA)、工程檢查 X 射線 ( EntityB) 和美術分析 X 射線 ( EntityC)。三箱，但同樣的東西，以同樣的方式生產、加工和儲存。如果是這樣，我將有一個 Image 表，它自己ImageID獨立於EntityX表的 ID 和三個相交錶鍊接EntityX到Image. 桌子是

EntityA(ID, OtherStuff)
Image(ImageID, Name, MoreColumns)
ImageA(EntityAID, ImageID)
ImageB(EntityBID, ImageID)
ImageC(EntityCID, ImageID)

如果這些圖像是非常不同的東西，並且在實際使用中沒有密切關係，比如 MP3 文件、pdf 文件和 JPG，那麼，肯定是分開ImageA的，ImageB和ImageC表格。

如果您確實為單個圖像表填充了主鍵，請確保您同時擁有ImageID和EntityTypeID。僅ImageID此而已，您最終將不得不協調 , 的主鍵EntityA，EntityB而EntityC這並不好玩。

引用自：https://dba.stackexchange.com/questions/63995