Re: Seeking advice on database table design for storing images

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: gearond(at)cvc(dot)net
Cc: pgsql-general(at)postgresql(dot)org, chris(dot)gamble(at)CPBINC(dot)com
Subject: Re: Seeking advice on database table design for storing images
Date: 2003-02-18 14:59:24
Message-ID: 3E524A4C.D6937955@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dennis Gearon wrote:
>
> It's faster to store the images in the file system, and the path/filename in the database.
>
> For one thing, the file system itself is just faster.
> You would have to provide the client's browser with a URL for the image, and feed that through
> some sort of switchyard script application, when with a filesystem based image, you just specifiy
> where it is and let apache worry about it.
>
> The only real advantage to putting images in the database, or hiding them behind another name in
> the document tree and using a switchyard application to redirect the image request is to protect
> your image directory and images from any use but in your site's documents (until they are
> downloaded once)

It's not the only advantage. What about making a consistent online
backup that includes a snapshot of the image collection? What about
session authenticated access to image data so that a user can only see
the images associated with an invoice where he has permissions for the
branch or department?

I store binary data b64-encoded in text fields.

Jan

>
> 2/7/2003 8:18:56 AM, chris(dot)gamble(at)CPBINC(dot)com wrote:
>
> >I am working on an application that will store images with every product
> >ordered from a given company. Doing this type of application on other
> >databases, I have always been told to use a seperate table for the image
> >store. Doing this has given me the table designs listed below. My question
> >is: Is it within the design of postgres 7.3 to store 30k to 1mb images in a
> >bytea field, and if so can the two tables below be joined into a single
> >table without suffering adverse effects?
> >
> >TABLE - tdatInvoiceLineItems
> >invoiceid int8
> >productid int4
> >quantityordered int4
> >samplestocustomer int4
> >adcost numeric 10,4
> >adheight float4 4
> >adwidth float4 4
> >workorderid int8
> >objectid int8 8
> >needsart bool
> >
> >TABLE - tdatCustomerArt
> >lineitemid int8
> >artwork bytea
> >extension varchar
> >
> >
> >Chris Gamble
> >CPB Inc
> >p: 972-579-1642 x 22
> >f: 972-579-1355
> >
> >
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 5: Have you checked our extensive FAQ?
> >
> >http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-02-18 15:09:53 Re: Aggregate definition : small oversight ?
Previous Message Tom Lane 2003-02-18 14:56:52 Re: Transaction Logs Recycling Problem