how to insert a picture in database

[ranga shreya]

I am developing an application. Where I am using pictures.. wanted to store in tabel. How can I store it in oracle database tables.
While getting the data from the database what is the way to do it in java to show it in jsp.

[Jeanne Boyarsky]

Ranga,
You can store the picture in a BLOB object. Search for "Blob" in this forum or the Sun JDBC tutorial for an example.

[abhishek gowlikar]

As per my experience never store picture on Database,Better to store Images on the folder which direct to the folder stored on the server,but address to be stored on the database.


like say we are storing some test.jpg store it on folder

img/test.jpg but the Relative Addres to be stored on

http://machinename:port/img/test.jpg

[Scott Johnson]

As per my experience never store picture on Database,Better to store Images on the folder

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.

[Rajah Nagur]

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.

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) and the image name and the url needs to be constructed dynamically retrieving from the database.

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.

[Scott Johnson]

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.

How can you guarantee that the filesystem stays synchronized with the database? Yes, it's possible, but you have to write extra code to do it. Especially if the filesystem can be modified from outside the code that maintains the images. What if some bored system admin decides the filesystem needs more free space and nukes half of the images. Now you have to write a batch process to periodically scan the file system and compare it to the database. I've been there. It's no fun.

Database network calls are very expensive. Its definitely not a good idea to store images in the database.

I disagree. If your database is properly configured, blob retrieval is very fast. Virtually as fast as retrieving the image from a filesystem.

The images are served by the webserver. IMO, images need to stored in the filesytem, preferably webserver filesystem (helps caching)

Images stored in blobs and returned as a servlet response can be cached at the web layer just as you would cache any other servlet response.

Why do images need commit/rollback i.e to have transaction capabilities? I don't see any business need.

I have an application where updates to images and metadata must be kept synchronized. If you change an image, the associated metadata must be changed as well. If the transaction is rolled back for any reason, all changes must be rolled back including the image change. This particular application is quite complex and images and image metadata are a small part of each entity. There are many business rules that could cause a transaction to abort.

Keeping things simple is difficult, making it complex is easier.

Now that I agree with!

[Rajah Nagur]

Lets be practical.
Storing images in DB has more overhead than filesystem.
Even the backup and maintenance become nighmare.
Check these links -- link1and link2

[ August 24, 2006: Message edited by: Rajah Nagur ]
[ August 24, 2006: Message edited by: Rajah Nagur ]

[Scott Johnson]

Storing images in DB has more overhead than filesystem.

Maybe. But depending on the application it might be worth it.

Even the backup and maintenance become nighmare.

Why would backing up a database (using the vendor supplied tools/scripts) be more difficult than backing up a file system?