Storing binaries in database: do I miss some drawbacks in this particular situation?

问题

I know this theme has been widely discussed in the past, and I thoroughly analysed the many insightful answers on the matter - confirming my idea that, generally, storing blobs in the db is bad practice.

Now let's take a look at the following scenarios:

• There's users, which has a one-to-many relationship with images;
• The images rows would contain, apart from users' FK and some metadata (date, title...), the following binaries (or file paths pointing to the following binaries):
  • Thumbnail (a ridiculously small binary);
  • Fullsize (will actually be preprocessed, to be about 400x600 and around 35-45kb;
• I will never need any data from the images table without an image as well (and anyway, I know where not to use SELECT *);
• I want to use fs and memory cache;
• In the most common scenario, I'll just need the thumbs (only getting the fullsize images dynamically on some events and, in those cases, getting them by ID). Clarifying: either many very very small pictures or one still pretty small one per call;
• Users will want to change their pictures' data, delete them, change them a lot.

Everything seems to make me think that the DB solution is optimal.

Are there drawbacks I fail to see (apart from the obvious open db connection in the event of no cache)?

回答1:

One problem in this scenario is making backups, or syncing a "development" or "test" environment with the production one (moving around a db dump would be painful). It's also much more simpler to edit en masse all the images, if they are on fs (say: mass create a new size for the images).

Anyway, I don't fully get into the real advantages of this approach versus a "pointers in db, files on fs" one. The memory cache, perhaps? These days when I think about blobs, I think of S3 anyway :)

来源：https://stackoverflow.com/questions/7237451/storing-binaries-in-database-do-i-miss-some-drawbacks-in-this-particular-situat