Associating data with uploaded files

Where to store the attributes?

[RossWal]

I need to create a mini content management type thingie in .Net. Users will upload files (probably Word docs), and while doing so assign a few attributes (like Author, Group, Title, etc). I'm trying to figure out where to keep the attribute information. I'm considering a stub file with the attribute text in it, meaning each uploaded file would have an associated stub file created. Another option is a single XML file that houses the attributes and relates them to their underlying content files via path/file name. I'm wondering if anyone has any thoughts or comments before I move forward?

Thanks

[andreasfriedrich]

If you are using word files why do users need to supply attributes (like Author, Group, Title, etc) when they can and should be specified within the word document? Just read those attributes. Avoid redundant data.

Andreas

[duckhunter]

You certainly don't want to limit the types of files. What about asking that information in fields on the same form you will supply the path to the file via the filebrowser.

ie:
Author:
Title:
File to Upload:

[RossWal]

andreas, as noted by duck, I can't guarantee they will always be word docs. Also, not all the attributes I need are available as Word properties. Lastly, I need to be able to access the information programatically, and I'm not sure how to do that, though I'm sure it's doable. I think MS does it in Siteserver 3.

duck, yupp, I'll collect the information as the file is uploaded, but I'm trying to decide where to store it on the server. In a common XML file, separate stub files, or what. Having given it some more thought, I'm leaning towards XML to take advantage of the XML reading and writing capabilities built into .net. Other suggestions still most welcome.

Thanks for your interest.

[duckhunter]

XML will certainly work. Do you have a database at your disposal? A table could store the filename and path and a child table with records for each attribute.

This would largely depend on the number of files you are talking about. More than a few hundred and the searching for text and keeping things readily accessible go out the window with individual XML files. You could use a single XML file but once again, scaling past a few hundred documents gets tough because of file size.

I love XML but it can be slow. It is great to work with when there is a limited amount of data. More than 100K and the database route starts gaining speed advantages. Not to mention the added security of your data.

Thoughts?

[RossWal]

I don't foresee scaling as an isuue in this case, so I'm going to jump in on the XML approach. Thanks for your thoughts.