9 Replies - 910 Views - Last Post: 22 November 2008 - 01:53 PM Rate Topic: -----

#1 ludjer   User is offline

  • D.I.C Head

Reputation: 15
  • View blog
  • Posts: 186
  • Joined: 31-October 08

big report and file website

Post icon  Posted 22 November 2008 - 03:36 AM

hey Dream.In.Code

i have been given a job to design a database of some sort where i have to store reports that are in doc,pdf,jpg etc
i have decided to create a database mysql database and store everything in the DB.
the site wont be traffic heavy, maby 0-50 visitors a day
there are gona be over a lot of reports added weekly,

i have read up that storing files in a database is not that good, for the situation that im in is it better then using a flat file system with folders to separate the different reports ?

thanks in advance

edit
here is a layout structure of my db, everything is linked i think :D
Posted Image

This post has been edited by ludjer: 22 November 2008 - 03:39 AM


Is This A Good Question/Topic? 0
  • +

Replies To: big report and file website

#2 Hary   User is offline

  • D.I.C Regular

Reputation: 44
  • View blog
  • Posts: 427
  • Joined: 23-September 08

Re: big report and file website

Posted 22 November 2008 - 03:49 AM

Storing files in a database is indeed not a smart solution. You can either store them in a flat directory using a generated filename, or in subdirectories which generated or original filenames.

In your ER, you added the foreign keys yourself, instead of drawing a connector line. These lines are the power of such diagrams. Please do use them.

* Does a user need to log on? There is nothing for that in your DB.
* A user has a company(text), but you have a company table. You'd better use company.Id as a foreign key (ie store the company id for a user)
* Drop the blob for the file and store it on the filesystem. That won't clutter your database.
* Reports has a files(int). What is it for? The numbers of files associated to that report, you can count from the files table. It's duplicate information which can become inconsistent. You dont need it.
Was This Post Helpful? 1
  • +
  • -

#3 ludjer   User is offline

  • D.I.C Head

Reputation: 15
  • View blog
  • Posts: 186
  • Joined: 31-October 08

Re: big report and file website

Posted 22 November 2008 - 03:57 AM

so storing files in a file system is a much better solution.
how does big file hosts like rapid share etc store there files, also on files systems, cause i thought it would be easy to manage having everything on one table, thanks for the tips with the database structure will fix it up
dont have to much experience with big websites only 18,just started working on this site for my one friends father :D
Was This Post Helpful? 0
  • +
  • -

#4 CTphpnwb   User is offline

  • D.I.C Lover
  • member icon

Reputation: 3795
  • View blog
  • Posts: 13,738
  • Joined: 08-August 08

Re: big report and file website

Posted 22 November 2008 - 06:59 AM

Store references to the files in the database. I would add filepath to your files table.
Was This Post Helpful? 0
  • +
  • -

#5 AdaHacker   User is offline

  • Resident Curmudgeon

Reputation: 463
  • View blog
  • Posts: 820
  • Joined: 17-June 08

Re: big report and file website

Posted 22 November 2008 - 10:37 AM

View Postludjer, on 22 Nov, 2008 - 04:57 AM, said:

how does big file hosts like rapid share etc store there files, also on files systems, cause i thought it would be easy to manage having everything on one table

I would advise you to not even think about how sites of that size store files. I don't know exactly what RapidShare does, but their solution will definitely be massive overkill for your needs.

Sites like RapidShare are dealing with massive amounts of storage, i.e. at least several terabytes. There are a few ways of managing that kind of data, but none of them involve storing all the files in one database table. That method works for small sites, but it just doesn't scale up to something the size of RapidShare. The management benefits would quickly be canceled out by the additional database load. The database is only going to store information on where to find the file, whether that's a file path, a URI, or some other kind of lookup key.
Was This Post Helpful? 1
  • +
  • -

#6 ludjer   User is offline

  • D.I.C Head

Reputation: 15
  • View blog
  • Posts: 186
  • Joined: 31-October 08

Re: big report and file website

Posted 22 November 2008 - 12:51 PM

oh ok thanks for that info AdaHacker

and just one more question
should i store it in multiple folders like a folder tree, or should a store everything in 1 folder with a generated name depending on the date and what report it is?
Was This Post Helpful? 0
  • +
  • -

#7 Valek   User is offline

  • The Real Skynet
  • member icon

Reputation: 544
  • View blog
  • Posts: 1,713
  • Joined: 08-November 08

Re: big report and file website

Posted 22 November 2008 - 12:52 PM

Ask yourself that question, and consider which would be easier for you to sort through. The organization is something you'll have to deal with personally, so go with what works best for you in that regard :)
Was This Post Helpful? 0
  • +
  • -

#8 AdaHacker   User is offline

  • Resident Curmudgeon

Reputation: 463
  • View blog
  • Posts: 820
  • Joined: 17-June 08

Re: big report and file website

Posted 22 November 2008 - 01:48 PM

View Postludjer, on 22 Nov, 2008 - 01:51 PM, said:

should i store it in multiple folders like a folder tree, or should a store everything in 1 folder with a generated name depending on the date and what report it is?

Depends on how many files you're going to have. If you're going to have many thousands of files, then you absolutely should not store them all in the same directory. Ever try to do a simple listing on a directory with 20,000 files? Things like that get really slow on huge directories. With large numbers of files you should definitely use some sort of hierarchy, perhaps based on date or type or something like that. The key is just to choose your organization so that no single directory gets too big.

If you're never going to have that many files - maybe a couple thousand or less - then it doesn't make that much difference in terms of performance. Just choose some directory structure and/or file naming scheme that makes sense for your data. The exact organization you use isn't that critical, just so long as it's logical and consistent.
Was This Post Helpful? 0
  • +
  • -

#9 ludjer   User is offline

  • D.I.C Head

Reputation: 15
  • View blog
  • Posts: 186
  • Joined: 31-October 08

Re: big report and file website

Posted 22 November 2008 - 01:52 PM

thanks for all the input now, i think im gona structure it like this:
company/province/site/{reportid}/
and all the report files, images, docs will go in ther ^^

thanks alot for every1's input
Was This Post Helpful? 0
  • +
  • -

#10 Hary   User is offline

  • D.I.C Regular

Reputation: 44
  • View blog
  • Posts: 427
  • Joined: 23-September 08

Re: big report and file website

Posted 22 November 2008 - 01:53 PM

It also depends whether you need to have a look at the files manually (for debugging f.i.) Making a subdir per user is an option, just think of what you think is best for your needs. Anything will work, just think what is the easiest for you.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1