What should I do? I have more than 1600 Images. Should I store them directly in the application or store them in a database. Right now I'm storing in Application and my application gets hanged so please Help
Exact Duplicate: User Images: Database or filesystem storage?
Exact Duplicate: Storing images in database: Yea or nay?
Exact Duplicate: Should I store my images in the database or folders?
Exact Duplicate: Would you store binary data in database or folders?
Exact Duplicate: Store pictures as files or or the database for a web app?
Exact Duplicate: Storing a small number of images: blob or fs?
Exact Duplicate: [store image in filesystem or database?][7]
As with most issues, it's not as simple as it sounds. There are cases where it would make sense to store the images in the database.
You are storing images that are
changing dynamically, say invoices
and you wanted to get an invoice as
it was on 1 Jan 2007?
The government wants you to maintain
6 years of history Images stored in
the database do not require a
different backup strategy. Images
stored on filesystem do
It is easier to control access to the
images if they are in a database.
Idle admins can access any folder on
disk. It takes a really determined
admin to go snooping in a database to
extract the images
On the other hand there are problems associated
Require additional code to extract
and stream the images
Latency may be slower than direct
file access
Heavier load on the web server
This answer is quoted from "Conrad"
As pointed out previously, it depends.
One of the most common practices is to decide on the basis of the images' size.
For very small images, such as thumbnails, icons etc, you certainly store them in the DB, and you can store them as a field of an entity (say a contact).
For medium sized images, it still makes sense to store them in the DB. However, you have to decide by yourself what is a medium sized image (my threshold is 1 MByte), and you should store the image not as a field of an entity: you should create an image entity and a relation to the interested entity (say the contact).
Finally, very large images should not be stored in the DB. You store them on disk and store on the DB their pathnames. This is necessary owing to the different latency and access time of the hard disk versus the DB. Indeed, it is the DB fast access through indexes that allows you to store medium and small sized images in the DB, but huge images should be handled differently.
Related
I must provide a solution where user can upload files and they must be stored together with some metadata, and this may grow really big.
Access to these files must be controlled, so they want me to just store them in DB BLOBs, but I fear PostgreSQL won't handle it properly over time.
My first idea was use some NoSQL DB solution, but I couldn't find any that would replace a good RDBMS and elegantly store files together. Then I thought on just saving these files in HD somewhere WebServer won't serve them, name them their table ID, and just load them on RAM and print them with proper content-type.
Could anyone suggest me any better solution for this?
I had the requirement to store many images (with some meta data) and allow controlled access to them, here is what I did.
To the cloud™
I save the image files in Amazon S3. My local database holds the metadata with the S3 location of the file as one column. When an authenticated and authorized user needs to see the file they hit a URL in my system (where the authentication and authorization checks occur) which then generates a pre-signed, expiring URL for the image and sends a redirect back to the browser. The browser is then able to load the image for a given amount of time (as specified in the signature within the URL.)
With this solution I have user level access to the resources and I don't have to store them as BLOBs or anything like that which may grow unwieldy over time. I also don't use MY bandwidth to stream the files to the client and get cheap, redundant storage for them. Obviously the suitability of this solution will depend on the nature of the binary files you are looking to store and your level of trust in Amazon. The world doesn't end if there is a slip and someone sees an image from my system they shouldn't. YMMV.
Some discussions in Stackoverflow say that storing the picture in DB is a bad idea (a because overtime, the number of images get large & may lead to app crash). So, either
a. the image can be stored in the iPhone itself & only its location can be stored in the DB
Potential Issue: The image might get removed (outside of the app) & the app might not be able to load them the next time
b. the image can be shrunk to a small size (say, 100*100 pixels) and stored in the DB
Potential Issue: will size be an issue if the image is shrunk to just 100x100pixels?
c. Doing both (a) & (b). So, small versions of the images will be stored in the DB and then, retrieved & displayed in the App, whereas, if the user chooses to see the original version of the image (whose probability is low), then that'll be fetched from the local directory & shown.
Your suggestions please? In my opinion, (c) seems a good option to go in for, in case (a) has the potential issue mentioned.
It really depends on where the images are coming from. Are they being downloaded from the Internet (or imported from the user's library / camera) after the user installs the app, or are they bundled with the app from the App Store?
If the images are being downloaded / imported, the best solution is to store images in the filesystem following the recommendations in http://developer.apple.com/library/ios/#qa/qa1719/_index.html
Basically, if the images cannot be replaced or recreated, store them in the <Application_Home>/Documents directory and do not set the Do Not Backup attribute. These items will be backed up to iCloud, and this data does persist for at least some amount of time even if the app is deleted from the device. (Remember that your users do not have unlimited iCloud space. Be responsible.)
-However-
If the images are bundled with the app, the best solution is to import them directly into your Xcode project and reference them from there. This way you know they are always available even if the user deletes and reinstalls the app.
I would definitely stay away from storing image data in the databased whenever possible. There are simply better, more efficient ways in most any scenario.
I want to store some photos that I take from a web service to my phone for the case when I don't have internet connectivity. I am storing data to a database but i have a question: should I store in the database the URL of the photo and the photo in a folder, or store the image in the database? The volume of photos shouldn't be great; something like 200-300 small pics, at approx 30-40kB each.
If you already have a database, i would organize my photos in database with only the path to the photo. And the photos can be stored on memorycard or on local disk.
The basic rule of thumb is to put big data objects like images right onto the disk and only reference the URLs. This might come in handy for loading/processing the images anyway.
30-40 kB per image is not that much, but then I'd consider 6-12 MB for the database quite extensive, especially it's probably the majority of your database volume.
I'm not real familiar with iOS. But my understanding is that it supports XML files. If the database is just being used to store the paths (instead of images), why not use an xml file to store the paths?
If you need the db, with small images, I don't see it being a problem if the phone is just using it. Either way, I don't think it'll be an issue. Someone else can probably give you a better answer as far as efficiency. That's outside my jurisdiction.
Store all the pics in document folder, and when there is no internet connection get them from document folder of your iPhone.
I don't know which is the most efficient way of organizing images downloaded from server. I will be downloading around 200 images on to my iPhone on request for download. Which is the most efficient way of organizing ? just dropping it as a file on the phone's memory or having it in sqlite (via coredata) after download ? which one is most efficient and easy to handle ? which access is faster ?
The rule of thumb is to put them (or any bigger binary data) onto disk directly, and if the whole app organizes its data with a database / CoreData, then put the paths of the images in there.
AFAIK , Iphone has minimum 8GB of memory. That will be enough for images. Also It depends upon the frequency of image downloads. If you download 200images daily then u need some application that will push it in your sqlite db. Advantage of this will be your all image files will be inside a single db. No scattered images. But if you want to store only 200 images then i would recommend it store on your phone memory with some image managing tool like ACDSEE in windows, that will help you viewing images in slide show or what ever manner you want.
What approach is considered to be the best to store and manage video files? As databases are used for small textual data, are databases good enough to handle huge amounts of video/audio data? Are databases, the formidable solution?
Apart from size of hard disk space required for centrally managing video/audio/image content, what are the requirements of hosting such a server?
I would not store big files, like videos, in the database ; instead, I would :
store the files on disk, in the filesystem
and only store the name of the file (plus some metadata like content-type, size) in the database.
You have to consider, at least, those few points :
database is generally harder to scale than disks :
having a DB that has a size of several dozens/hundreds/more GB because of videos will make many things (backup, for example) really hard.
do you want to put more read-load on your DB servers, to serve... files ?
samer thing when writting "files" to your DB, btw
serving files (like, say, videos) from the filesystem is something that webservers do pretty well -- you can even use something lighter (like lighttpd, nginx, ...) than the webserver used to run your application (Apache, IIS, ...), if needed
it allows your application and/or some background scripts to do some tasks (like generating previews/thumbnails, for example) without involving the DB server
Using plain old files will also probably make things much easier the day you want to use some kind of CDN to distribute your videos to users.
And here are a couple of other questions/answers that might interest you :
Storing Images in DB - Yea or Nay?
Storing Images : DB or File System -
Store images(jpg,gif,png) in filesystem or DB?
store image in database or in a system file ?
Those questions/answers are about images ; but the idea will be exactly the same for videos -- except that videos will be much bigger than images !