Thanks,<br />Ranga.<br />Life is precious so enjoy the life each moment and utilise it at the same time.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
As per my experience never store picture on Database,Better to store Images on the folder
Originally posted by Scott Johnson:
I disagree. Storing images in a database is not necessarily a bad idea.
The problem with storing the images on a file system is that it can become out of sync with the database. You can't enforce referential integrity between a table and filesystem. Permissions are enforced/administered differently. Files are accessed via a different API. (You can't use JDBC to access a filesystem!) Commit/rollback of transactions involving files is more difficult -- you'd have to rollback the file changes manually.
One drawback to storing images in a database is that they can use a large amount of space in the database.
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Referential integrity can be enforced with the image name and not with the actual images. The image name only needs to be stored in the database and not the complete image.
Database network calls are very expensive. Its definitely not a good idea to store images in the database.
The images are served by the webserver. IMO, images need to stored in the filesytem, preferably webserver filesystem (helps caching)
Why do images need commit/rollback i.e to have transaction capabilities? I don't see any business need.
Keeping things simple is difficult, making it complex is easier.
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Storing images in DB has more overhead than filesystem.
Even the backup and maintenance become nighmare.