Posted by Jerry Stuckle on 03/28/07 14:55

Geoff Berrow wrote:
> Message-ID: <4LadncMb3JhkwpfbnZ2dnUVZ_uWlnZ2d@comcast.com> from Jerry
> Stuckle contained the following:
>
>>> If there were functions that could extract meta data about the image
>>> (filename, size, type etc) then I think you would have a point. As it
>>> is, you are simply using the database /as/ a filesystem when it clearly
>>> isn't. Now that's not to say that that is a bad idea necessarily, I can
>>> see arguments for adopting this approach (portability and ease of
>>> maintenance for example) as well as arguments against.
>> But it is relational. Every post in here has had comments about storing
>> the path to the file in the database. So if the path is relational
>> data, why isn't the data?
>
> That's beside the point. (well my point anyway) A one hour video
> documentary might be relational also, would you store that in a db too?
>
> Stuff in a database can usually be processed in some way (which is why I
> added the caveat about functions that may be able to extract or
> manipulate image data)
>

Not necessarily. There's a lot of data in a database which is just
retrieved. For instance, do you normally search on every field in every
table? I don't. I.E. it's rather uncommon to "process" a street
address. You store it and retrieve it. Very seldom do you actually
search on it.

> Another thing we haven't talked about is data redundancy and
> normalisation.
>
> Let's say you have a membership list. Some people have provided an
> image others haven't and you decide to use a placeholder image instead
> (ok I'm sure /you/ wouldn't but less experienced programmers might). In
> this case you'd have to upload multiple copies of the placeholder image.
> And if the placeholder image changes, all files would need to be
> rewritten.
>

Not if you've created the database properly you don't. You can easily
have a single placeholder image and have multiple members point at that
same image.

> Say I have a CMS storing data about a site. A page may have images that
> appear on other pages. To normalise the database you would need a
> separate table for the images. Again, less experienced users may store
> multiple copies of the images.
>
>

You're just describing a normal many-to-many relationship, which, in a
normalized database, is always implemented with at least three tables.
In this case the page table, the image table and a link table. Just SOP.

And just because someone is less experienced and creates a bad design
doesn't mean that it's a bad idea. That person could also create a
separate directory in the file system for each page - and store multiple
copies of the image there. Does that mean it's a bad idea to use the
file system to store images?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]