3 ms·
>you'll have to write your own two-phase commit logic to ensure when row X is deleted, then /wherever/X.jpg is also deleted I can't imagine a situation where y
by nemothekid 8y ago
>you'll have to write your own two-phase commit logic to ensure when row X is deleted, then /wherever/X.jpg is also deleted
I can't imagine a situation where you would need strict consistency with a BLOB and a database row unless you were also modifying bits inside the BLOB (which wouldn't be true if you are hosting images).
If you just need to ensure that whenever user X says DELETE, you can put S3 infront of an API and just query the database before you return the URL. If you really need the file gone, I would rather just encrypt the image and store the key in the database row.
In a world where S3 doesn't exist, I would still build something similar because coupling my object store with my actual data store just seems like asking for trouble. Having to wait hours to backup several kilobytes of changed data in a multi-terabyte database is just inviting people to cut corners.
- kbenson 8y agoStoring legal contracts associated with accounts. I implemented a system like this. Documents were simple and usually small, pure html with no images or hrml converted to PDF, occassionally it was an attached JPEG from something someone emailed or faxed. If you want a system where the documents are strictly linked to the account, easy to query based on account, consistent (in the DB sense), replicated and backed up with all the other very important customer info, and local so you aren't exposed to external risk factors it's the path of least resistance, and can be easily and securely implemented with very little effort. Different solutions for different needs.
- gravypod 8y agoOne situation I had was storing consent forms for medical patients. If we enabled their care in the DB and lost their consent form we could be sued for quite a bit.