-1

At this point, I'm not much of a programmer, solid html/css, familiar with JS but not a programmer by any means. I'm looking to pick up whatever is necessary for an upcoming project.

I need to build an online image repository that will host around 15k photos. Those photos will need to have user entered data associated with them. They will need to be searchable by tags, and batch downloadable.

Would you guys do filesystem or db storage? Basically, what type of storage solution would you use?

gnat
  • 21,442
  • 29
  • 112
  • 288
user2680994
  • 1
  • 2
  • Have you looked at GridFS? It allows you to store files in chunks and attach arbitrary metadata. – Stefan Billiet Jan 28 '14 at 07:11
  • I removed the part of the question about the framework recommendation to avoid that your question would be closed soon. Questions asking for offsite resources are off-topic for this site, next time you ask a question please read the FAQ first. – Doc Brown Jan 28 '14 at 07:13
  • In this case it's probably best to store in the filesystem and use the image metadata systems (like exif, iptc, xmp) since when the file is brought out of the system to be used that data will be retained. Also a lot of Digital Asset Management software can use it to build a database out of the box. It's also probably cheaper to use that than to roll your own software. – James Snell Jan 28 '14 at 14:24

3 Answers3

4

The approach I would use typically for such a constellation is

  • store the images in the file system

  • use a database for the meta data (including references to the related image file names)

The reason for this is that you will need indexing and transactional security for your meta data, but typically not for "parts" of your images (I guess they will be updated only by adding new ones or deleting old ones, the only thing for images you need transactional securrity for is that two different images won't get the same file name, but that is a meta data operation).

Note that there are some databases out there which can handle the storage exactly that way for you, so you can access all the data, including images, by SQL in a transactional manner, but the DB stores the images in separate files in the background.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
1

This might be one of those rare situations where I recommend considering a 3rd party solution that you can modify. In addition to open source gallery software, there's plenty of gallery plugins for various CMS's.

If you must write this yourself, for the volume you are talking about it doesn't really matter where you put the images - either way it will work. But, if you are expecting high traffic, it'd be better for them to be on the file system, so that your database server doesn't have to handle the overload of serving the files. Also, keeping the images in the file system can provide you more flexibility regarding backups.

GrandmasterB
  • 37,990
  • 7
  • 78
  • 131
1

Storing files in the filesystem is surely a good quick solution which works and I personally would never suggest to store files in a database not even on those rare occasions in which it could be done.

On another note however consider that storing files in the filesystem directly from a web applications is generally not the clean solution.

In some frameworks for instance it breaks common guidelines, see for instance the JavaEE guidelines here: http://www.oracle.com/technetwork/java/restrictions-142267.html, in this case your are breaking the Server model if you "create, modify, or delete files in the filesystem".

This because storing files directly in the filesystem is not scalable to the cloud where servers could be running in different virtual machines across dozens of hard disks.

In Java the suggested solution would be using a standard container like Apache JackRabbit.

Sandra G
  • 163
  • 6