|
|
Posted by Jerry Stuckle on 03/28/07 14:48
Tim Streater wrote:
> In article <4LadncMb3JhkwpfbnZ2dnUVZ_uWlnZ2d@comcast.com>,
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> Geoff Berrow wrote:
>>> Message-ID: <8OmdncdWe6syIJTbnZ2dnUVZ_qXinZ2d@comcast.com> from Jerry
>>> Stuckle contained the following:
>>>
>>>>> Why? Why would I *want* to put non-relational data in a relational
>>>>> database? Why would I *want* to use a database as a filesystem?
>>>>>
>>>>> Just saying "it works fine" is not enough.
>>>>>
>>>> Because it IS RELATIONAL. It is related to other data in the database.
>>> 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?
>
> Don't think I was talking about storing the path. Definitely the file
> itself, in my example.
>
> -- tim
Tim,
Sure, it works fine. As I said, I've done it a lot of times. And yes,
there are some really good reasons for keeping it in a database.
You need to design carefully to have good response, however. Generally
I've found it helps to keep the image/scanned doc/whatever in a separate
table consisting only of the id, the blob and what you will need only
when you display it (i.e. for an image you might want the size). Other
things like a description, etc. keep in its own table. This keeps the
load down on the server and makes for faster response.
But this is still off topic in a PHP newsgroup. A database newsgroup
would be better.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|