2017-02-26 101 views
0

前一段時間,我實現了一個帶有全局預定義目錄結構(不可修改)的gdrive /類似於dropbox的應用程序,每個用戶都可以使用該目錄結構,但不限於(意思是:也能夠添加和管理自定義文件夾)。數據庫中許多相關數據的相同數據

靜態目錄結構是這篇文章的原因,因爲我不滿意目前的處理機制,並且會非常高興,如果你能給我一個很好的建議,我可以改進它/改變這個更好。

目前我使用一個MySQL數據庫,其中有一個表'文件夾',這(驚喜,驚喜)包含所有文件夾(預定義和自定義)。因此它具有文件夾名稱,所有者和父文件夾的字段。

因爲預定義的結構非常龐大,所以我不想爲每個用戶添加它到表中,因此我只用此結構的一個實例爲文件夾表添加並將「owner」字段設置爲NULL 。因此,要查找用戶的所有文件夾,我只需要查詢將此特定用戶作爲所有者或不屬於任何人的那些文件夾。

這種方法目前效果很好,但對於文件夾的每個用戶屬性有一些主要缺點,例如,我想在每個目錄中顯示文檔計數 - 包括子目錄 - 這是每次使用非常慢的遞歸查詢完成的。如果我只有每個用戶文件夾結構(例如,通過添加一個額外的「文檔計數」字段,可以更好地處理這個問題),每當文件夾中的文檔發生某些事情時可以使用查詢掛鉤來更新該字段結構體)。

您對這個設計選擇有什麼看法?我是否應該保持這種狀態,只需添加一個包含每個用戶文件夾屬性的附加表(例如像user_id,folder_id,document_count,last_modified,[我可以想到的任何其他屬性])?如果直接在系統上處理文件夾(通過使用系統命令)並將它們保存在數據庫之外,這會是一種更好的方法嗎?或者你有沒有其他的想法(或許是更合適的數據庫?),這可以用更方便的方式進行管理。

感謝您的幫助! :-)

+0

多個用戶可以使用特定的文件夾? –

+0

多少個文件夾?用戶?文件?等等?你在說什麼?數百萬,或只有數千。只有成千上萬,我建議建立一個邏輯結構,而不是擔心性能。對於數百萬人,我們來看看一些實際的模式和查詢。 _使用這兩種方法之一,您可以編寫性能不佳的查詢._ –

回答

1

如果我理解正確,您將存儲數據庫中的所有文件。所以你可能有一個表files包含文件(二進制)以及他們的文件夾ID。因此,所有文件夾都是名稱後才能讓用戶構建數據並輕鬆訪問。但是這也意味着,您不必在數據庫中將此設置爲分層結構,您必須使用遞歸查詢進行掃描。

假設在A裏有一個固定的文件夾A和一個固定的文件夾B.用戶添加了三個文件夾。這些都是用戶在folders表中的記錄:

 
id folder_path user_id 
1  A    1   (every user has this) 
2  A/B   1   (every user has this) 
3  A/B/C   1 
4  D    1 
5  D/E   1 

如果用戶打開他們的存儲,它們顯示的所有主要文件夾(那些沒有在folder_path破折號):A和D.如果用戶打開的一個文件夾,比方說,你看裏面的所有文件夾(即所有開始A/folder_path有一個破折號):在我們的例子A/B,再加上所有文件folder_id 1.如果用戶重命名BF然後更改每folder_path與開始代替A/BA/F開頭。如果用戶將F移動到E的內部,則每改變folder_path,以A/B/F開始改爲以D/E/F開始。

計數文件一樣容易:

select count(*) 
from files 
where folder_id in (select id from folders where folder_path like 'A/B%'); 

所有這些都是簡單的操作,因爲什麼事都沒有實際移動,你永遠只能仰望的文件夾,其中開始具有一定的字符串或你的路徑'd改變文件夾路徑的開始。

+0

感謝您的回覆! 對不起,我沒有說清楚:是的,有一個文檔表,但它不包含文檔本身,而是一個路徑(與文件夾數據庫中的虛擬路徑無關)到文件它所引用的文件系統。但是,對於您的建議解決方案而言,這並不重要,它仍然適用並似乎至少解決了文檔計數問題。如果這真的解決了所有的要求,我需要更徹底地考慮這一點,但目前看起來如此。再次感謝! :-) – Tek