TOM_RUS has a FileDataLib posted on CurseForge now that is a better version of the paste I made earlier (he also compacts the data by splitting filenames and filepaths into different arrays and then combines them at runtime):
http://wow.curseforge.com/addons/filedatalib/
I believe it can still be greatly improved as there are some missing features that are desirable (such as a reverse lookup) and it is also bloated because it contains nearly everything (I poked TOM about removing many file types that the API literally can't reference, though, which should help).
Originally Posted by Ketho
But the API is getting less and less consistent  *looks at the new model:GetModelFileID* |
Yes, this is a problem because there are actually 3 types of FileDataID now. Here's a basic overview.
FileDataID- The primary means of referencing any file in modern WoW
- Implemented in CASC's 'root' file alongside nameHash as the only ways to lookup a file
ModelFileDataID- Used internally to reference model files in almost all cases (spell visuals seem to go directly to FileDataID in a few places because being consistent is hard)
- Used to bunch many different FileDataIDs together who have the same purpose but slightly different characteristics. For example, a helmet item will reference 1 ModelFileDataID, which in turn will resolve into a different FileDataID for every race/gender combination. The characteristics supported in this grouping process are: RaceID, SexID, SpecID, and 'Order' (0 = left shoulder, 1 = right shoulder, -1 = everything else).
- Implemented by ComponentModelFileData.db2 (details the characteristics) and ModelFileData.db2 (groups the FileDataIDs by ModelFileDataID).
TextureFileDataID- Used internally to reference texture files in almost all cases (UI rendering seems to go directly to FileDataID in a few places because being consistent is hard)
- Used to bunch many different FileDataIDs together who have the same purpose but slightly different characteristics. For example, a chestpiece item will reference several TextureFileDataIDs, which in turn will resolve into a different FileDataID for each gender (chests on female characters have to use different textures). The three characteristics supported in this grouping process are: RaceID, SexID, and SpecID.
- Implemented by ComponentTextureFileData.db2 (details the characteristics) and TextureFileData.db2 (groups the FileDataIDs by TextureFileDataID).
The API is inconsistent in both its parameters and returns. Part of the blame lies in the inconsistencies of the internal data structures (as I briefly noted in the summaries above), but this is then compounded by more inconsistencies on the API side. For example, SetTexture only takes FileDataIDs and filenames but not TextureFileDataIDs, but model:GetModelFileID only returns ModelFileDataIDs (also, they shorten the real name to 'ModelFileID', which bothers me).
Looking back at this post, this is probably valuable information for the wiki somewhere too.