aspose file tools*
The moose likes JDBC and the fly likes how to insert a picture in database Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "how to insert a picture in database" Watch "how to insert a picture in database" New topic
Author

how to insert a picture in database

ranga shreya
Greenhorn

Joined: Mar 05, 2005
Posts: 20
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.


Thanks,<br />Ranga.<br />Life is precious so enjoy the life each moment and utilise it at the same time.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30947
    
158

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


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
abhishek gowlikar
Greenhorn

Joined: Aug 17, 2006
Posts: 13
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
Ranch Hand

Joined: Aug 24, 2005
Posts: 518

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
Ranch Hand

Joined: Nov 06, 2002
Posts: 239
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.


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>
Scott Johnson
Ranch Hand

Joined: Aug 24, 2005
Posts: 518

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
Ranch Hand

Joined: Nov 06, 2002
Posts: 239
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
Ranch Hand

Joined: Aug 24, 2005
Posts: 518
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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: how to insert a picture in database