Subject Re: [firebird-support] Re: Files or FDB to store images?
Author Aage Johansen
Steve Wiser wrote:

>>> ...
>> ...
>
> Yeah, if we would have taken the time to work out some type of clean way
> to have the code keep the directories to a manageable level we probably
> would have kept the files out of the db. I still cannot really say
> which approach works better as I don't have any experience with a large
> amount of images in a filesystem with database links to them. I do know
> that a lot of image workflow products do not store their images in the
> database, just the link.
>
> BTW, how is the SAN working out? We are still up in the air about
> whether or not we really need one... I kind of want to stay away from
> fibre channel and go with iSCSI even though it is not as fast at this
> time.

We're using an Dell|EMC AX100, connected to one server. Two servers can be
connected (and share storage) (with more that two servers you need a
switch). It justs sits there and from the users's point of view it
is just another disk. It has solved the problem of storage for the
Netware server (which has 300+GB of local disk). IIRC, the SAN now has 4
disks (@ 250GB) (in RAID-5, I believe), but the cabinet can hold 12 disks.
So far, there has been no problems. And, speed has not been an issue.
We could have connected a database server to the device as well, just
giving a part of the storage to that server. I haven't tried it, but it
"should work" as the servers should see the storage as a local disk.


> ... ...
>
> When we show a tiff image on the web we just select it out and set the
> content type and let the browser figure out what to do (normally Windows
> Picture and Fax viewer or something like that will handle it). We do
> have to do some bulk prints of tiff images (try not to, but sometimes
> they can't data enter from the image) and we use ImageLib from SkyLine
> Tools (www.imagelib.com). Seems to work well.

ImageLib is what we use (after starting out with just the "imaging" program
included with WinNT and Win2k).


--
Aage J.