2011-09-21 21 views
4

我想知道是否爲每個用戶創建一個文件夾是一個壞主意。因此,每個用戶的任何圖像都可以通過訪問img.mysite.com/UserId/image.jpg爲每個用戶創建一個文件夾的不好主意?

+1

您可以將所有圖片放在一個文件夾中,並將所有圖片與數據庫中的所有者相關聯,並根據需要使用乾淨的網址! –

+2

那些說這是一個「可怕的想法」的人,請解釋爲什麼這是一個壞主意?例如,我個人不明白爲什麼這會成爲ext4文件系統的問題。 – Arafangion

+1

好的主要問題是照片的數量將呈指數級增長。所以我不希望他們都卡在一個文件夾中。亞當斯的答案似乎也有助於解決這個問題。 –

回答

4

這可能會變成大量的目錄,所以請注意,因爲some filesystems限制了單個目錄中子目錄的數量。將生成的內容分解成多個目錄是很常見的。你可以通過日期來完成,或者分解一些標識符(一個散列或圖像的自動增量ID號)來創建一個更深的目錄結構。例如:

  • 化身/ 000 /(圖像1-999)
  • 化身/ 001 /(圖像1000年至1999年)
  • 化身/ 002 /(圖像2000年至2999年)

又名目錄前綴是floor(ID/1000)

無論如何,從文件系統中抽象URI的可能性很大,所以文件存儲在後端的位置並不重要,除了作爲程序員。

1

不,這不是最好的主意。

如果單獨文件夾的唯一目的是爲了讓您可以在您建議的結構中具有「友好」網址,那麼我建議您搜索URL重寫

如果你想解決一些其他問題,請發表評論,並告訴我們。

+0

不是唯一的原因,但絕對是其中之一。我的另一個擔心是,如果有一個目錄將容納所有照片的問題。照片的數量將是100,000+ –

+1

如果它需要人類可讀,即一些窮人將不得不手動瀏覽一個100,000文件夾中的特定照片,那麼我會同意多文件夾選項。但是(聽起來)這是一臺電腦的工作,那麼它可以處理任務。 – Widor

1

沒有理由爲什麼從性能的角度來看這將是一個問題。從組織的角度來看,它比把它們全部放在同一個文件夾中要乾淨得多。

+0

這不是一個資源問題,因爲有些服務器只允許特定數量的文件夾? –

+0

如果您使用ls或通過ftp出於某種原因訪問該目錄,則列出目錄內容可能會很慢。 – dsas

0

我認爲這將是更好的格式:
http://img.mysite.com/userid_imageid.jpg

然後,你可以做數據庫是這樣的:

表上的FTP usersimgs

+1

是的,這是一個很好的結構。 經常需要替換原始圖像名稱。 通常你會發現像imagelinks:fgh6tfjj65zg47tcjtrd.jpg 這是*嘗試*,以避免直接訪問圖像 - 隱私或大規模抓取。 我想提一下,使用「cdn」 - 內容傳遞域來提供靜態內容(如圖像)是個不錯的主意。 – EO2

0

使用一個文件夾,並製作好並固定的數據庫,同一個人的所有照片都鏈接在一起。沒有那麼難:)

5

絕對壞主意,我會從我的經驗
在最近的過去我工作的一個應用程序,它是基於社交網絡
說,現在有大約15000+用戶。

另外我現在正在管理該網站。

與此問題的是,你會發現它很酷,首先要管理,但稍後它會成爲一個問題。
必須始終跟蹤權限。
創建和刪除相對於您的數據庫的文件夾以實現同步。
另外如果你在共享主機,許多託管服務提供商,他們不顯示所有的文件夾與任何文件管理器。可以通過文件管理器可以看到的最大數量的文件夾2000客戶服務支持,你只能訪問第一個10000夾。 文件夾的非ASCII名稱將與數據庫的名稱一樣是另一個問題。

這對你以後會是一個很大的問題。

我會建議不要用這種方式去。

+0

你可以分裂文件夾,愚蠢。沒有人要求您在同一目錄中創建所有15k。 –

+1

根據文件系統的不同,如果您使用非ASCII名稱,這也是一個問題。 (但是爲什麼引入複雜性?) – Arafangion

+1

數字ID之後名稱文件夾也沒有問題。這只是你的錯,如果你使用用戶名 –

0

對於較小的網站,它不是一個可怕的想法,有一點需要注意:

MUST抽象文件創建/刪除處理爲一體的機制!

確保所有的代碼都使用這種機制,它應該能夠存儲和檢索和刪除,就是這樣。然後,如果您想改變存儲文件的方式,可以非常輕鬆地完成。

P.S.當我說你所有的代碼時,我的意思是全部你的代碼。例如,我會有任何GET匹配

^img.mysite.com/(\w+)/(\w+\.jpg)$ 

處理由一個單一的方法,它調用我上面描述的機制。

相關問題