CODEWITHSUNDEEP
phpmysql
adamK
adamK

Reputation: 3889

Best practise for handling images in a CMS

A quick question on best practice for handling images in a PHP/MySQL CMS. Each item will have a varying number of associated images which will be stored in folders referenced by the items ID. Validation is done on upload so all files should be valid. My question is whether I should also store the ID and filename(s) in a database table and pull the source data from the DB or is it OK to simply iterate through the folder and insert the source filenames directly?

I hope that makes sense. Thanks in advance for any advice.

Upvotes: 0

Views: 941

Answers (1)

zamnuts
zamnuts

Reputation: 9582

It largely depends on how many points of failure you want and the speed of the response time.

If you store it on the filesystem:

  1. Incoming HTTP request
  2. PHP queries the database
  3. The database finds the row
  4. PHP deciphers the query response
  5. PHP reads the file
  6. PHP sends the file's binary contents as a response to the HTTP request

However, if you store it as a binary blob in a database:

  1. Incoming HTTP request
  2. PHP queries the database
  3. The database finds the row
  4. PHP deciphers the query response
  5. PHP sends the binary contents as a response to the HTTP request

In both cases step 3 (the database finds the row) can be just as fast with our WITHOUT the blob column as long as proper indices/keys are set up. MySQL will move the pointer to the exact indexed position internally - it won't actually go through every byte until it finds the right one (that's the whole point of an index). This is just as time consuming as PHP reading the file manually. However, I currently do not have supporting performance data to support this.

Now let me talk about points of failiure:

  • Let's say you migrate your data. If your binary image data is stored in the database, you just move the database. However, if your binary image data is stored on the file system, you have to remember to move both. Also note that the SIZE of the migration would be identical (or at least minimally different).
  • Consider renaming an asset - you'll have to rename it not only in the database, but also on the file system. That's 2 total steps as opposed to renaming it in the DB which is only 1.
  • Consider deleting the asset - you'll have to delete it in both locations.

I have always stored binary data as a blob in the database for the purpose of portability, flexibility, and minimizing failure or corruption.

If you choose to store the file in the database as a blob, consider the different blob storage requirements: http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html#id656744

  • TINYBLOB - 256 bytes
  • MEDIUMBLOB - 64 kilobytes
  • LONGBLOB - 4 gigabytes

Lastly, just food for thought: I have experience working with Adobe's Day CQ which is an up-and-coming enterprise-level content management system. It is primarily written in Java, but what is important to note is the data architecture. It uses a JCR (Java Content Repository) which more or less acts like a multidimensional MySQL database (kinda cool?). All image data in its DAM (digital asset manager) is stored as a node within the JCR.

Upvotes: 1

Related Questions