2012-12-27 118 views
3

我正在開發一個網站,上傳到網站的單個圖像可以由多個業務模塊用於像食品畫廊或什麼的。
我有一個主要的圖像表存儲對文件系統上的實際圖像的引用。
現在,此表上的每個記錄都可以通過項目,菜餚或圖庫表引用。
我的問題是,如果所有這些引用存儲在一張桌子上,或者我應該維護一個單獨的表,如ItemImage,DishImage?
單桌問題是我擔心這張桌子會被高命中轟炸,最終增加響應時間。多個表格的問題是隨着模塊數量的增加,我不得不增加更多的表格。
如果我說性能是我網站的重中之重,那麼最好的方法是什麼?最佳實踐,用於存儲圖像引用數據庫

SQL Server 2012中,.NET 4.5,MVC 4

感謝

+0

*表格可以包含數以百萬計的數百萬條記錄。這不是問題*相反,請考慮:模型中「圖像類型」的*角色*是什麼?它是'xImage',其中'x'代表未定或增長集合中的某些東西?或者'x'是否代表了一個有限的選擇集合(與其他表格有關)中的一個值?這個問題聽起來像是前者,在這種情況下......這是直接的答案! – 2012-12-27 01:17:44

+0

所以說食物和圖像是多對多的? –

+0

我將使用單個表格 – chamara

回答

5

我會推薦使用一張表。正如@Brandon所說的,如果索引正確,就不應該有性能問題。

我還建議你只存儲一個來自通用根文件夾的相對路徑(如@SpectralGhost推薦的那樣)。通用根文件夾可以是一個配置設置,允許操作團隊更改文件的存儲位置,而無需對數據庫進行批量更新。

如果在單個文件夾中有數千個文件,文件系統性能可能會成爲問題。我建議爲更多的樹結構創建幾個子文件夾級別。例如,如果文件名是ABCDE.jpg,那麼使用像A/B/ABCDE.jpg這樣的路徑將文件分割成數千個子文件夾。

我還建議您使用GUID或類似名稱作爲上傳文件的基本文件名以避免任何命名衝突(並使用無用的GUID版本來保存4個字符)。如果您需要原始文件名,請將其放在圖像表的另一列中。存儲其他圖像元數據,例如寬度,高度和Content-Type(例如「image/jpeg」)也是一個好主意。

使用關鍵字標記系統對每個圖像進行分類可能是對圖像進行邏輯分組的最佳方法。然後理論上可以將每幅圖像分配給任意數量的類別(包括零)。這將需要一個標籤列表表和一個包含(tag_id, image_id)對的單獨映射表。

+0

感謝您回答未知的問題。 –

4

這是存在哪些索引。將它們全部放在一張表中,只要它被編入索引,對於這種情況,性能不會成爲問題。

想想如果你有一本書有1,000,000頁的書。即使對於你作爲人類來說,只要頁面是有序的,就不需要很長的時間才能找到任何給定的頁碼。在100,000,000頁的書中找到頁面的時間差別實際上不會太長。

現在,如果您對數據進行復雜的報告,它可能會有所不同,但這只是查找表。