I need some opinion and comment.

[shelbytll]

Hi, I would like some opinion.
For a web based document management system, do you think the file system should follow exactly the way the files are stored? Currently, when a document is uploaded, it will create a folder for that document. So one folder for a document. And the folder name is the FolderID in the database. This is because there will be document with the same name and I don't want to rename coz it will be an attachment in the email. I prefer this way coz the management can be done in the database itself. No need to handle the file system side. So base on the information in the database, I can display out the folder architecture to the end-user. For example subfolder in folder etc. Just that in the file system, it is all one folder one document kind of look.

Any suggestion, comment and opinion? Thanks I am a clever newbie...

 

[Mdiaz]

I would dump uploaded files into a single directory or maybe a select few. Keep in mind that the power of your database can be used to administer files and do house keeping. For example, files that need to be pitched after two years can filtered and deleted using a query. The DB knows where the files exist so creating a folder/directory for each file is not really necessary.

Thats my 2 cents.

Mike Diaz...

 

[shelbytll]

But if you dump all files into one directory, how about files with the same name? You will need to rename the fiels. Because when we send out email with that file, the filename is important.

So you don't think it's necessary to make the file system in the explorer style?


Storing the document into the database is out for me. I am a clever newbie...

 

[Tarwn]

Heres a thought. If your storing the pathname in the database, then create 5 folders. When someone uploads a file check to see if there is already one in the first folder with that name, if there isn't upload to the directory and write the path to the db, if there is then go to the next folder and repeat. Sure if someone uploads 5 files with the same name it will take an extra second or so, but thats what they get for not using unique filenames

5 wa justa random number, if you have truly stubborn users that never change their filenames then this of course wouldn't work.

-Tarwn ________________________________________________________________________________
Want to get great answers to your Tek-Tips questions? Have a look at faq333-2924

 

[shelbytll]

Hi Tarwn,

we can't limit the number of times they will upload with the same file name. The best is make it unlimited.

But now I'm arguing should the file system maintain the same architecture to that they wanted? For example they created a folder, then create a sub folder under that folder. Should my file system follow exactly this way? Currently my file system are not. It is just one folder one document. But of coz when they access the web site, it is displayed according to what they had created. I am a clever newbie...

 

[Mdiaz]

I use a fileupload component to upload files.

I have used:

SAFileUp; by softartisans.com

ASPUpLoad; by persits.com

Both of these have extensive properties and methods which allow a user to upload a file. If a file with an existing name already exist then it cancanates a "(1) to the file name, if FileName(1).ext already exist then it will name it FileName(2).ext, and so on and so on (file name I used is just made up).

Then when you update your DB it stores the uploaded file name whether FileName.ext or FileName(1).ext, or whatever.

You can also code teh application to advise the user that the file name is already being used and to use another file name.

The components also allow you to set file size and file type restrictions.

Mike Diaz...

 

[shelbytll]

Hi Mdiaz,

please know that the problem is not about storing document with the same file name. A document management system will definitely have document with the same name coz they need to retrieve the document, edit and then upload back.


the problem is with the file system (window explorer). Should I make the file system in a hierarchical manner like our normal file system. When we click on C drive, u'll see Program Files, Windows, Documents and Settings etc etc. Do you think it's better to make it this way or one folder one document kind of manner.

Advantages is that when we move this document from this folder to that folder, we simply manage the information in the database. We no need to physically move the file in the file system. I am a clever newbie...

 

[Tarwn]

Aaah, I get it it now Pardon me for being a little alower than usual. You mean the architecture of the navigation or hierarchy that gets displayed while they are browsing the files through as web page, correct?
I would guess that it would probably be easier to look at the files without the folders you created. The user doesn't know about those folders so you probably don't want to confuse them more than necessary (Despite that being the users default state ).
If you are keeping track of the path, filename, date, and user all seperately in the database than what you could do is select the files back in a fake hierarchy. Maybe by user name. So what you could do is show them a directory of all the users (Select all the users distinct from your db uploaded files table). Then when they click on a user you can display all the files that user uploaded (select all where user = user they clicked on order by filename, date).

Basically I think that if your gong to show them a hierarchy at all, it should seem to have some sort of order to it. Showing them how you actually have it layed out means they only see one file in every subfolder, whereas creating a pseudo hierarchy will seem more realistic and easy to use to the end user. The pseudo user folders I suggested above were only one option, but theres no reason you couldn't create the hierarchy dependant on anything you imagine. Maybe you want it to look lke there are a 26 (24? alphabet...argh) folders each one letter of the alphabet, and then in those folders are the files that start with the given letter ("select * where filename like '"&yourletter&"%'&quot
Basically just treat this as you would any search results page. Show them a minimum amount of information, when they click on one show them more information based on what they click.

Hope this made sense,
-Tarwn ________________________________________________________________________________
Want to get great answers to your Tek-Tips questions? Have a look at faq333-2924

 

[shelbytll]

Hi Tarwn,

No, it is not the architecture of the navigation or hierarchy that gets displayed while they are browsing the files through as WEB PAGE. The web page should display the hierarchy architecture with all the folder and sub folder because those are created by them. For example I created a folder call Shelby and under Shelby, I created 2 sub folders called Project1 and Project2. Naturally I would want to see the architecture I created. The web page is the front end. What I meant is the back end. When you open up your Window Explorer. Is it better to see exacly what you saw on the web page? I am a clever newbie...

 

[Tarwn]

Now I am extremely confused.

Let me ask some questions in order to clarify before I get to tangled up again. Please excuse me if some of them seem obvious or repititous, I am trying to visualize your system.

1) The user can create folders and subfolders from the web page, correct?

2) When the user uploads a file, you create a new directory where they want to upload the file and place the file in that new directory?

3) This architecture is what is shown in the web page, but you are asking whether you should really create all the folders the user wants to create (so you can see them in windows explorer)?

3.5) By viewing in windows explorer are you speaking of you yourself viewing the files in windows explorer, or are your users going to have dual access where they can either view the website or connect with something like a mapped drive or network connection and view them in windows explorer themselves?

I know those seem basic and explained before, but I think that these three (and a half) answers are what I need to know in order to visualize the system the same way your are.

-Tarwn ________________________________________________________________________________
Want to get great answers to your Tek-Tips questions? Have a look at faq333-2924

 

[shelbytll]

1) Correct

2) Yes, when user upload a file, physically create a new folder and put that file inside. Folder Name is the FileID in database. Note that when user create a new folder in web page, it does not physically create a new folder in the window explorer. It is all done in the database. So the displaying of hierachical architecture is based on the database info.

3) User only have access to web page, not the window explorer.


However when developing this web application, my boss thinks that it is better for the back end system (window explorer) to be same like what is displayed on the web page. He argue that what if the database crash? At least the file system architecture is there. I am a clever newbie...

 

[Tarwn]

Ok, I understand now. I think this comes down to a personal opinion. I wouldn't bother with the extra folders as they would server no real purpose other than to bloat the hard drive.
Concerning the possibility of a db crash:
1) If there is database driven login, it makes the whole thing moot since the users won't even be able to login
2) I have yet to see a db crash, but as long as you keep it backed up you should be fine. In the event of a crash, if for some strange reason your data were going to be corrupted there would be problems whether or not the hierarchy followed the one the user is setting up, because the actual filenames are mapped to the users in the database so you wouldn't have that mapping information any more.
3) Were you planning on making a back up system that will run entirely off of FSO? If so than it might make sense to make the folders match so that the one time the db goes down it can serve out the folders to the users still during the ten minutes it takes to reboot and recover, unless the db is on the web server...than by the time the web server is back up and capable of being switched to the back up system you already have the database up.

Anyways, I think these are the major things to consider, sorry it took me so long to understand,

-Tarwn ________________________________________________________________________________
Want to get great answers to your Tek-Tips questions? Have a look at faq333-2924