Should I store file information in a database for a php based file manager?

Question

I'm looking to build a basic file management component for the system I'm working on (php, javascript, sencha). I'm trying to convince myself one way or the other on whether I need to store extra information in a database about files being managed through the system. On one hand, I'm reluctant to complicate a simple design by trying to ensure that information stored in the database is reflected in the filesystem. I imagine a nightmare ensues if they become out of sync for whatever reason. I.e. the path is not updated correctly. It just seems easier to rely on whats in the filesystem. I don't need any control mechanisms like ACL.

For the most part, the directory structures are hidden from the user as they really don't care where in the filesystem they are being stored. Kinda like email attachments. The attachments are related to other data in the database. My initial idea was to create the relationship within the filesystem by using directories. For example:

Root
...Project_id_1
......Theme_id_1
.........Topic_id_1
.........Topic_id_2
.........Topic_id_3
......Theme_id_2
......Theme_id_3
...Project_id_2
...Project_id_3

The ID would be the record ID of the item in the database its related too. I think this would work just fine, except when I need to display this as a tree view. I will need to extract the relationship for each directory so I could display meaningful names. Maybe this is a fine trade off for the simplicity gained elsewhere. I.e. not having to rename directories with every topic name change.

If I did decide to store more information in the DB about every file, what would I stand to gain besides useful (but not necessary) information like who uploaded it, date, etc, etc. Of course, any other reasons I should consider other designs would be appreciated as well. Most of the OTS stuff, either offers too much functionality I don't need or be too much work to retrofit into the system.

Answer 1

I guess the key question is whether the additional information you store would be of sufficient value to be worth the trouble. If you build it, will they come?

I've seen lots of systems where someone went to a lot of work without bothering to ask, Will anyone care?

I don't know what your users want or need, so without a lot more information I can't answer the question for you.

Update

In reply to your comment:

I have stored information about files in a database when there were relationships that I needed to keep track of. The first example that comes to mind is a web app for tracking suggested design changes to equipment our organization produced, where users could add attachments (Word docs with more detail, engineering drawings, whatever) to their recommendations that would be uploaded and associated with the record for the design change. So we tossed all these files in a directory somewhere, and then in the database had a record for each attachment that tied it back to the design change record. I forget now if there was any data in there besides the key of the design change record and the file name, but there certainly could have been things like when uploaded, by whom, etc.

Answer 2

I would say:

For today: no. Do not create work based on a possible future need.

For tomorrow? Yes, as soon as you actually need to. You mention you already have a database, so its not like you have to bite off a lot of overhead.