[thelist] Images--database or file

[john at johnallsopp.co.uk]

Cool, so I'm pretty much doing the right thing, nice to know. Nice
system Bob.

Cheers
J

> Similar situation for me;
>
> Folders for different sizes of images, (eg thumbs, main etc.) and then
> just a file name in the db. Makes changing images etc a lot quicker
> and easier. Also means you can move stuff around quickly.
>
> Austin
>
> ----- "Bob Meetin" <ontheroad at frii.com> wrote:
>> path <==> gallery_name
>>
>> i am using different directory names for different file sizes,
>> sometimes
>> i have many versions of a file in different sizes:
>>
>> 75x75
>> 100x75
>> 100x100
>> 120x80
>> 200x150
>> 360x270
>> original
>> etc.
>>
>> i set up a standard upper path that all fit under.  the files are
>> associated with the gallery name, not path - might look like
>> "/gallery/images/200x150/file_name.png".  200x150 houses both
>> portrait
>>
>> and landscape and a p/l field is stored in the database.  i don't
>> know
>>
>> how to use blob to get files into the database, so can't comment on
>> how
>> well it works - that is another lesson.  security is as Joel said.
>> also
>> to note, when files are uploaded i rename all to lower-case and
>> remove
>>
>> spaces.  -Bob
>>
>> Joel D Canfield wrote:
>> >> Which way is best, tho?
>> >>
>> >
>> > er, how 'bout I offer what I do without claiming it's 'best' -
>> files
>> in
>> > a directory structure, path in the db.
>> >
>> > I prefer it because the files *can* be accessed outside the
>> database
>> > structure if that's desirable. if not, security lockdown cures
>> that.
>> > path can be changed, it can be parsed and rebuilt on the fly using
>> UNC,
>> > local path, web address. db can be copied elsewhere as a reference
>> to
>> > what's available, without requiring the bigness of storing all the
>> data.
>> >
>> > one downside is that moving/copying the db requires the additional
>> step
>> > for the directory structure, but I can deal with that.
>> >
>> > joel
>> >