Results 1 to 12 of 12
  1. #1
    Join Date
    Jun 2004
    Posts
    25

    Unanswered: Reducing Database Size (contains images)

    Hello. I am wondering how to effectively reduce the size of my database. After viewing the individual table sizes, I have come to realize that nearly 99% of the database's size is due to images. I am told that too much binary data is not good. How can I go about reducing the size of my database (possibly the images themselves)? I'd appreciate any help.

  2. #2
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    store the path and filename instead of the image?

    Do you use READTEXT WRITETEXT alot?

    what's the size of a average image?
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  3. #3
    Join Date
    Jun 2004
    Posts
    25
    The average size is around 680k. I do not use readtext and writetext a lot. How do i go about storing the path instead of the actual image?

  4. #4
    Join Date
    Jun 2004
    Posts
    25
    Someone suggested a UNC path to the images. What is this?

  5. #5
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    UNC = Universal Naming Convention

    \\servername\sharename\pathname\filename.img

    so you can place the images anywhere
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  6. #6
    Join Date
    Jun 2004
    Posts
    25
    is there an easy way to do this if I have around 360 images that need to be moved? What do i put in the table's data field

  7. #7
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    UNC=\\SERVER\SHARE\FILENAME.EXT

    There are kudos of reasons to store images in the database itself. It all depends on the app itself, and what is actually stored in those images. I prefer to use image and (n)text fields, because that's what a database is for. And if there is anything that is associated with the business through your app, - its place is in the database. The question comes how this info is being used. For example, in healthcare industry it becomes more and more practical to do high-speed scanning of claims. Scanned images are burned onto media of choice. Some organizations are also storing those images into database (TIFF format), others go even further and apply OCR technology to avoid data entry process. Key elements of the claim image are stored in related tables to meet search needs. The only time the image field is accessed is when there is a need to view the original claim. Will it make sense to store a path to a TIFF file instead of the file itself? Does the database have any control over OS environment? NO!!! In other cases Full-Text Search capability is used if the type of file being stored meets the parsing and filtering capabilities of the search engine (Word documents for example.) Whoever told you that "too much binary data is not good" is operating under unqualified assumptions. You need to look into the nature of the business usage of your app and determine whether it does or does not make sense to rely on database for safe-keeping of your images (I think the answer is pretty clear, hey?!)
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  8. #8
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    And the debate starts again....

    If you have significant volume...I'd say it's an issue...

    Hell they went out and bought kodak imagining platter to handle everything...it's massive...

    no way a db could handle this volume...

    There's also the pain of reaind and writing in chunks (how do you update a chunk again? Is it the whole thing?)

    How big are the images?

    http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=36026
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  9. #9
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    He told you, - 680K
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  10. #10
    Join Date
    Jun 2004
    Posts
    25
    My problem is that the database itself is far too large, and it is 99% due to these images. They are simply photos of employees and there are around 360 of them. We use them on a web site where once a name is typed in, info about that person is displayed; background info, history with the company, sales numbers, the photo, etc. How do i go about creating this UNC to the images? Where do you recommend i save this pictures? I appreciate any help.

  11. #11
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    So, are we talking about less than 250MB worth of images? If this size is taken by 1% of your structure, then your database is less than 500MB all together. Why are you concerned about this? Why are you calling it "a problem?"
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  12. #12
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    What is far too large?

    If the pix are 1 mb you only be saving 360 mb

    That's not big
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •