給定一組將具有關聯元數據的文件，那麼存儲此元數據的推薦方法是什麼？一些文件格式支持在內部存儲元數據（EXIF，ID3等），但並非所有的文件格式都支持這種格式，那麼更普遍的選擇是什麼？存儲與單個文件關聯的元數據的方法？
某些元數據幾乎肯定是唯一的（標題/描述/等），而有些元數據會不同程度地重複（類別/標籤等）。
如果需要不同類型的屬性，對元數據進行分組也可能很有用。
理想情況下，解決方案應該涵蓋概念，而不是特定的語言實現。
一種選擇可能是一個關係數據庫，結構是這樣的：
FILE
f_id
f_location
f_title
f_description
ATTRIBUTE
a_id
a_label
VALUE
v_id
v_label
METADATA
md_file
md_attribute
md_value
此實現具有一些獨特的信息（標題/描述）， 但在數據的重複羣體主要是針對性。
對於一些要求，其他較不通用的表可能更有用。
這有這是優勢關係型數據庫是很常見的， 顯然在處理人際關係和存儲大量的數據非常好。
但是，對於某些用途，數據庫服務器帶來的開銷可能並不理想。 另外，數據庫服務器與文件不同 - 它們不坐在一起，需要不同的交互方法。
數據庫不會（很容易）處於版本控制之下 - 這可能是好事還是壞事，取決於您的觀點和具體需求。
純文本比其他任何東西都有一些明顯的優勢。類似於
FileName = 'ferrari.gif'
Title = 'My brand new car'
Tags = 'cars', 'cool'
Related = 'michaelknight.mp3'
對於這類元數據，Picasa的Picasa.ini文件就是一個很好的示例。另外，不要發明自己的格式，而應該考慮XML。有很多現成的DOM處理器來處理這種格式。
然後，如果文件數量和它們之間的關係很大，數據庫可能會更好。
要在數據庫中存儲元數據有一些優點，但數據庫的主要問題是元數據不直接連接到您的數據。如果metada與數據保持一致，比如目錄中的特殊文件或類似的東西，它會更加健壯。
某些文件系統提供了可用於元數據的特殊功能 - 如NTFS Alternate streams。不幸的是，這隻能用於特殊情況下的元數據存儲，因爲在將數據複製到不支持它的存儲系統時，這些數據流很容易丟失。我相信linux文件系統也有類似的存儲機制。
無論如何，最常見的解決方案是：
IMO沒有通用的解決方案。我會選擇隱藏文件中的元數據存儲（健壯性），並使用數據庫進行快速訪問和緩存。
我認爲「解決方案」很大程度上取決於您將如何處理元數據。例如，我們存儲的幾乎所有元數據（科學數據的多個數據集）都被切碎並存儲在數據庫中。這使得我們可以創建數據集來保留文件之間的通用元數據（就像你說的，類別和標籤），同時我們有文件特定的結構（標題，開始/停止時間，最小值/最大值等）。雖然我們可以保持這些隱藏的文件，我們做了大量搜索，並通過Web服務向外部消費者開放我們的界面。
如果您存儲的是不會搜索的元數據，則隱藏文件或每個「真實」文件的專用.xml文件不是一個糟糕的路徑。它基本上可以讀取任何內容，可以輕鬆轉換爲不同的格式，並且在決定更改存儲機制時不會丟失。
元數據應該幫助你，而不是阻礙你。我已經看到（並已成爲其中的一部分）系統，其中元數據存儲比存儲實際數據變得更加繁重，併成爲一種負擔。只要記住你正在試圖用它做什麼，並且不要過度用「假設」來擴展自己。
我基本上會使得其持有此信息的元數據DB：
RESOURCE_TABLE
RESOURCE_ID
RESOURCE_TYPE（文件夾，文檔類型，網絡鏈接等）
RESOURCE_URL（任何URL）
NOTES_TABLE
NOTE_ID
RESOURCE_NO
RESOURCE_NOTE（長文本）
TAGS_TABLE
TAG_ID
RESOURCE_NO
TAG_TEXT
然後我會用備忘欄的文本註釋的文件/文件夾/資源。選擇是否使用1：1或1：N。
標籤字段我將用來存儲任何數量的可搜索參數，如YEAR，PROJECT以及其他將描述和分組您的內容的值。
然後，你可以添加表所有者，利益相關者和其他組織的信息等
[有沒有明文沒有這樣的事情（http://www.joelonsoftware.com/articles/Unicode.html ）。實際上，我現在正在尋找一種將文本字符集編碼存儲爲文件元數據的方法。 – 2014-01-18 13:32:29