我接受用戶的文件上傳。每個文件在db中都有一個指針，該指針具有文件系統中文件位置的信息。 目前，我將文件存儲在文件系統中非分類，並且每個文件當前僅被命名爲唯一值。所有的分類和命名等都是在應用程序中使用db完成的。未來證明文件存儲
我關心的一個因素是文件同步問題。 如果我想設置文件系統同步，例如用戶的文件是通過與PC應用程序橋接來自動更新的，那麼這個系統是否仍能正常工作？ 我不知道這樣的系統如何工作，所以希望我能得到一些輸入。
基本上，是純粹在數據庫中表現文件的名稱和位置最優化，特別是如果所述文件可能與pc應用程序同步？
所有你需要做這樣一個系統的工作是要確保你使用（或者，更可能的是，創建）API就可以以合理的方式跟我們的數據庫和文件系統。由於這是你的網站已經在做的事情，所以它不難實現。
事實上，您的文件被賦予標識符而不是純英文名稱，這與遠程同步方面大多無關。
將文件散列存儲在數據庫中而不是路徑（即SHA1），並有一個單獨的數據庫將散列與路徑相連接。編寫一個可以同步散列數據庫的小應用程序，以便在將文件移動到其他位置時，使用更新的路徑構建新數據庫將很容易。
通過這種方式，您還可以讓系統從不同位置加載文件，具體取決於您使用哪個散列數據庫來定位文件，以便在需要人員能夠從不同位置訪問同一文件時提供一些透明度（即nfs或webdav）。
是的，你這樣做的方式是最好的辦法。您正在使用文件系統來存儲文件和數據庫來損壞結構化數據。
我會做的一個建議是你在文件系統上創建一個目錄樹。您可能有一天會針對文件系統的每個目錄限制的最大文件數而運行。我已經建立了系統，爲每一天或每週創建一個新的子目錄。
確保您有良好的數據庫備份以及文檔存儲庫。
乏味的回答™：
我認爲這取決於你想做的事，一如既往:)
我的意思是把你常規的網絡託管公司。開發人員始終將文件同步到Web服務器。 Web服務器將散列生成的文件名存儲在指向物理文件的數據庫中是否有意義？不可以。然後你不能用你的FTP客戶端登錄並上傳這樣的文件，你必須編寫一個自定義模塊來讓Apache工作等等。即時頭痛。
Flickr使用db是否有意義？是的，一點沒錯！ （話又說回來，你不能用一個FTP客戶端登錄並管理您的照片，而這可能是一件好事！）
只要記住，一個文件系統是（很簡單），DB過。這是一個數據庫，有很多有用的免費工具。
我的2¢
/0
我們使用的正是這種模式用於文件存儲，用（無恥插頭）一起SabreDAV使它似乎最終用戶這是一個正常的文件系統。
我認爲這是一個非常好的模型，只要查找文件記錄和輕鬆檢索應該不會有問題。只需備份你的數據庫:)
我可以給一個其他的建議，我們使用文件id上的md5（）來生成一個唯一的文件名。我們使用的部分文件生成的目錄結構，例如.. ID 1將產生：b026324c6904b2a9cb4b88d6d61c81d1，產生的文件名會變成：
B02/632/4C6/904b2a9cb4b88d6d61c81d1這樣做的原因是，最穩定的文件系統可以在一個目錄中的大量文件（或目錄）之後變得非常慢。遍歷幾個子目錄要快得多。
關於每個文件系統的每個目錄限制的「最大」文件可能是什麼？同樣有一個頂點，尋求性能急劇下降？例如（完全是假的數字），如果在500個文件目錄中查找/訪問文件沒有問題，但5000之後性能會呈指數級下降......在15,000之後，系統會抓取......這將很好地瞭解這些統計信息。 – scunliffe 2011-02-04 14:43:48