New Capacity Limits RE: Container Field Images

[Jarvis]

Does the increased file size of FM7 mean I can now store jpeg images directly in the container fields, or is it still prudent to just include a reference to their location in another file?

Version: v6.x

Platform: Mac OS 9

[Mariano Peterson]

I think the answer to this question will be more apparent when FM Server 7 is released. The main problem with storing images in a database is that it takes space in the tables that must be searched. However, depending on the internal architecture of the database, the database could partition the tables to store the binary objects (images) in a different (partitioned?) location so as to provide access to the binary objects when necessary while still keeping the tables and indexes compact and efficient for searching and back end database file i/o.

[Ocean West]

You can store ANY file type including your JPEG images in in to a container field. This is good if you wish to give someone else the file they will have every file contained within. One example someone did is create a db with all the IRS tax forms as PDFs you can search for the form you want an then export the desired PDF.

IF you put the fp7 file on a cd or email it all the files go with

[Mariano Peterson]

Yes, those are excellent points.

[EddyB]

Hi Stephen,

Does this not affect the solutions performance, even if you have hundreds, maybe thousand of files contained within the solution itself?

If not then this is a great addition to FM!

Ed.

[Ocean West]

:shrug: sorry i don't know the answer for this one. I would assume that there is some sort of isolation of where files are store vs. data & structure. From what I saw it was a lot faster - I am sure the Smithsonian folks will be happy!

[bruceR]

I don't see why it should affect performance. Performance is more related to field indexes and record count. If you had 1000 records with 1MB container fields, vs 1000 records with 1MB of text in each text field, the text database would be wayyy slower.

[stanley]

To go back to Jarvis' original question about if it's a good idea to store within containers now (due to the file size limit being lifted) or not - it depends on what you're doing with the database.

If you're a single user, and you've got the hard drive space, why not? If you're on a networked system, you'll still want to watch out for all the normal pitfalls. One particular issue can be backing up the database. If you're burning backups to CD, and you're using references, the backup will not only fit on the CD, but it will still function (so long as the images/container-items are on a remote volume.) However, it's pretty easy to exceed the size-limit of a CD when you're storing images/container-items internally...

In the end, I don't think it makes a difference. If you were happy referencing before, then carry on. If you were putting items directly in container fields, then now you're free to romp wildly over your hard drive.

-Stanley

[dkemme]

I agree, until the capabilities of Server 7 are known, it will be difficult to say if one can leave large amounts of images in the file or store them by reference. It is much easier to keep them in the file if you are cross platform and/or across a large network with differing security firewalls. Until the performance of the server in sharing these images or backup times are known, it will be difficult to know which is best.