November 17, 2015 at 12:56 pm
Jeff, I've always been a fan of storing them in the db, but it's never one size fits all. The system I support now has 200+ TB - yes, TB - of images. Backup/restore of 200TB is doable I assume (have never done it), but it would be a lot of time/effort for things like refreshing our QA environment. Instead we store the pointers and the QA copy just points at the same files, though read only of course. We do suffer from orphaned records and pointers, but on a tiny scale and there is a clean up operation that finds/fixes/logs the problems.
November 18, 2015 at 8:35 am
Andy Warren (11/17/2015)
Jeff, I've always been a fan of storing them in the db, but it's never one size fits all. The system I support now has 200+ TB - yes, TB - of images. Backup/restore of 200TB is doable I assume (have never done it), but it would be a lot of time/effort for things like refreshing our QA environment. Instead we store the pointers and the QA copy just points at the same files, though read only of course. We do suffer from orphaned records and pointers, but on a tiny scale and there is a clean up operation that finds/fixes/logs the problems.
I agree with that. One size rarely fits all. But, just to confirm, you're having some of the same problems that I had with orphaned "records" and pointers except that I can't simply do a cleanup operation. If the files are lost, then I have some serious explaining to do even if I wasn't the one to do the initial design. Heh... and you've got to store that 200TB somewhere.
Backups are fairly easy because the table I'm storing things in is temporally partitioned, which allows me to make old months read only and only need one backup and on backup of the backup. Once done, those become static and I only need to backup the current month.
To be sure, though, my intent of the additional post was to imply that it truly does depend. Some are going to go with file pointers (a tried and true method) and some are going to store the data in the database. The real key is that I found that the general recommendation of only storing small binaries has it's faults, especially if there are no real, honest to goodness controls over the files themselves.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply