I had a similar case. The same shoe in different sizes appears as different "articles", but they may share the same pictures.

Of course, one-to-many relations are possible with tables, too, but I used the approach of saving the pictures as separate JPG-files.

>Hi Stefan
>
>I forgot to mention that in my app many records share pictures. The app I am referring to is an inventory system where we have pictures of more or less every of about 300000 articles, and since for instance a 5x20mm fuse looks the same no matter what rating it has, one picture is used for all these fuses. The same goes for resistors and many other articles. In my case putting the pictures into a memo file would be no option. For many other applications, yes, it may be an option, or maybe even the only practical solution.
>
>>Tore,
>>
>>I agree that the memo-based approach is much less attractive when updates can occur arbitrarily in any 'partition' (table) of a database that is live over an extended span of time. But if we talk 'CD-ROMs for customers' then this aspect does not apply, since CD-ROMs are frozen when they are manufactured (and CD-ROMs are so small that partitioning is not necessary and a single table will always do the job).
>>
>>As regards the other statement - would you find it acceptable if I upgraded the 'small' to 'medium'? ;-)
>>
>>Sure, file open performance can be improved dramatically by choosing an appropriate directory structure. But this addresses only one particular drawback of the file-based approach; the are others. On the other hand, the file-based approach does have unique advantages over the memo approach and so none of the approaches is superior to the other in all cases (I think I said as much in my earlier article).
>>
>>However, unless special considerations apply I still think it is more logical to put data into table columns instead of external files. *g*