一張表用於所有 blob，其中一對一表用於連結到一個或多個表的元數據？
首先我要說我不是 DBA，但我在目前項目中擔任了這個角色，所以我正在盡力而為。
- 應用程序必須能夠儲存文件（附件、官方文件等）
- 該應用程序使用實體框架 6 (EF6) 來查詢數據庫。
- 我正在使用的 Sql server (2012) 沒有啟動 FileStream/FileTables 功能，我不得不假設它永遠不會被啟動。
- 我無權訪問文件伺服器。
我不是唯一可以更改應用程序中 DAL 的人，而且我知道，如果您不小心使用 EF6 編寫查詢，預設情況下
select * from，因此在創建數據庫時我做出了選擇，為了安全起見，為所有 blob 創建一個表，其身份作為主鍵，並一對一映射到另一個包含元數據（文件名、上傳時間、上傳者等）的表。一個文件可以與許多其他表（數據集）有關係，一個數據集可以有多個文件。
我看到了兩種設計方式，我在這裡展示了 2 個數據集（notice 和 noticemaster），但我可以有更多；
選項 1
選項 2
我的問題是；哪一個是正確的實現？有選項3嗎？
獎金問題；我是否做出了一個不錯的選擇，為所有文件提供 1 個表，為所有元數據提供 1 個表？
這些模型中的任何一個看起來都是合理的。
NoticeMasterFile交集表不是嚴格需要的，因為您可以通過任一模型獲取資訊。問題是：您打算如何使用 NoticeMasterFile 資訊？也許這種改變會支持你的一些未來計劃。當然，問題在於查看數據模型並不能真正揭示模型背後的思想。
儘管如此，分離 blob 對我來說似乎是一個非常好的主意。如果沒有別的，當有人
SELECT *在FileMeta桌子上奔跑時，它會保護你。順便說一句，如果您使用 sp_tableoption 設置
'large value types out of row'=1blob，則會留下一個 16 字節的密鑰來引用 blob 頁面。該 blob 仍將被視為表的一部分。這種分離將允許您查詢其他列，FileMeta而無需處理 blob 數據的成本。（這是預設設置。）問題：您希望在您的數據庫中積累多少文件？平均尺寸有多大？等等？
如果您的文件負載相對較輕，那麼這應該沒問題。但請記住，每個文件都包含在您進行的備份中。
如果您認為您最終可能會進入 Terabyte 大小範圍，您應該對如何儲存文件做一些進一步的規劃。
可能：
- 考慮隨著數據的增長為文件創建一系列文件組。在適當的時候，將舊文件組設置為只讀。這可以保護數據並讓您可以選擇不那麼頻繁地備份它們。
- 要求您的企業重新考慮將文件儲存在文件系統中的價值。
就其價值而言，多年來我們一直在雙向進行，並且兩種方式都有其問題。但更多使用嵌入式文件的系統現在改用文件共享。