Tim Moores wrote:Images should not be stored in a DB. File systems are good for storing binary blobs
Tim Moores wrote:Images should not be stored in a DB. File systems are good for storing binary blobs, and just their metadata should go into the DB.
Stephan van Hulst wrote:What makes file systems better for blobs?
tangara goh wrote:I was told to store encoded Base 64 strings into the DB
but then how do MongoDB comes in ?
Tim, Your file systems refer to ? It can't be harddisk right ? Doesn't make sense...
tangara goh wrote:
I was told to store encoded Base 64 strings into the DB...
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
Tim Moores wrote:You're right, I should be precise instead of making a half joke. I fixed my post.
Tim Holloway wrote:
tangara goh wrote:
I was told to store encoded Base 64 strings into the DB...
That's a horrible thing to do. Base64 is very space-inefficient. It was designed in part to email binary data between incompatible computers whose byte sizes could be as small as 6 bytes. So typically a Base64 translation of data will be at least twice as big as the original data.
Sorry Tim, is base64 and encoded base64 the same thing. I checked back my message - the person just mentioned base64.
A better solution, as we've said, it to upload the images as independent files to an image directory and store the pathname of the image fine in MongoDB (or whatever SQL/NoSQL database you prefer).
tangara goh wrote:The image directory should be what kind of location ?
cos it can't be your local hard drive when you will be hosting the app eventually right ?
just to confirm we don't need Mongodb GridFS to store the image ?
I'm going to be a "small government" candidate. I'll be the government. Just me. No one else.
just to confirm we don't need Mongodb GridFS to store the image ?
I have seen in my googly that people actually created a POJO class just for the file alone and then they have timestamp, fileName the metadata you mentioned. Is this necessary?
now I feel this MongoDB is kind of pointless since the image is already all in the fileServer.... so I would just store everything including the metaData at MYSQL but is metaData really matters ? cos the file will be associated with another Entity (for this case Pet) so why the need to have metedata?
Stephan van Hulst wrote:
Tim Moores wrote:You're right, I should be precise instead of making a half joke. I fixed my post.
It was a serious question though, I'm not a big DB buff. What reason is there to prefer using a file system over saving the image as a blob in the DB?
Tim Moores wrote:
I have seen in my googly that people actually created a POJO class just for the file alone and then they have timestamp, fileName the metadata you mentioned. Is this necessary?
now I feel this MongoDB is kind of pointless since the image is already all in the fileServer.... so I would just store everything including the metaData at MYSQL but is metaData really matters ? cos the file will be associated with another Entity (for this case Pet) so why the need to have metedata?
Those are implementation details that depend on your circumstances. If you need to keep metadata, you obviously need to store it somewhere. Whether MySQL or MongoDB is the best place to do so, we can't know. Both can be used, so pick what makes sense for your situation. If you already use one of them, then it doesn't make sense to add the other just for the metadata, because, as I said, both can be used for that. If you're not sure what metadata you'd need, well, maybe you don't need any. That would be unusual in my experience, but it could happen.