Interessant.

With this partitioning scheme, how do you link the images to other data records - that is, do you use some key value to find them, comparable to the filename, if you store each image in a separate file?


I am aware of the problems of having too many files in a single directory.

However, I had only tested with a few images. I did some programming for the images, which, unfortunately, was never used seriously (somebody has to take the trouble of taking pictures of the shoes (in the shoe factory)...). If the amount of pictures grows, I thought, I would consider separating by directories.


>I don't think that the 2 GByte limit is an important factor in deciding whether to use memo fields or external files. If you have a lot of images then you need a partitioning scheme of sorts in any case (multiple tables in the case of .DBF, multiple directories in the case of external files).
>
>I can store about a quarter million images in a single Fox table but how many files can I put into a directory before accesses become prohibitively slow? 1000? 10000? So the partitioning needs a bit more thought in the file system case. In the Fox memo case I just partition at 650 MByte which is convenient for backup/archival onto MO, PD and CD-ROM. This is only one third of the possible maximum but the dispatch code doesn't care whether the master table has 100 records or 300 - it does just a single seek anyway. It does not matter where the tables are actually located on the network as long as they are registered in the master table.
>
>Similar things can be done with directories, it just won't be as easy.
>
>I think the major criteria against memo storage are:
>- necessity for shared access with other apps (paint program, webserver)
>- frequent updates, especially if update patterns run afoul of the partitioning