Posted by Geoff Berrow on 03/28/07 13:21

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)

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.

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.


--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[Back to original message]