9 Replies Latest reply on Jun 26, 2014 2:09 PM by philmodjunk

    Advice on how to OR not to build another database with portal

    ahutler

      Title

      Advice on how to OR not to build another database with portal

      Post

           Here is the situation: we have a large database that holds a lot/most of our collection information. I am thinking about building another database on a different drive and this database that will hold TIFF and JPEGS for certain records that are in the large database, but not all record entry’s(objects) from the large database have a TIFF image.

           It was recommended by our tech support to place this ‘new’ database on a specific drive. So would I create a relationship between the ‘New Image’ database on the separate drive with the ‘Old Large’ database and create a portal to transfer information to the new database, or should I just create a new layout in the Old Large database?

           For example, we have 1,000 paintings in the Old Large Database, and let’s say 100 paintings have multiple large TIFF image files that currently are not in the Old Large database, (but we could eventually have TIFFs for all 1,000 paintings)

           Do I create a new database with a relationship to Old Large Database and portal field information(#,artist’s name, title of painting, date of painting, etc..) into New Image database?

        • 1. Re: Advice on how to OR not to build another database with portal
          philmodjunk

               Can you explain more fully why you are doing this?

               Why a separate database?

               Why on a different drive? (I can see why you might use a dedicated drive for the image files, but why put the database on a separate drive?)

               What version of FileMaker are you using? (FileMaker 12 introduced some new features for working with container fields)

          • 2. Re: Advice on how to OR not to build another database with portal
            ahutler

                 Sure-

                 The idea was that this would be a seperate database that would hold images that are of the quality needed for: publications OR to be used on a website.

                 When consulting our IT people before starting this project (they are contracted to us) they suggested placing the images and new database on this drive (which is actually the same drive that the Old Large database is stored on??)

                 I don't know that it has to be seperate but that was the original thought, maybe so we wouldn't slow down the use of the Old Large database when looking through the large TIFF/JPEG files (I plan on creating buttons that download these images to staff computers)

                 We have version 12.

            • 3. Re: Advice on how to OR not to build another database with portal
              philmodjunk

                   If both sets of files are located on partitions of the same drive, I don't see how that will significantly improve performance. The same hardware has to read/write the data from the same storage media. Putting such a DB on a completely different computer server, on the other hand, could keep the "load" from accessing a very high resolution image from adversely affecting response times for other users using your original database.

                   You may want ask your IT folks to explain the reasoning behind their suggested change in greater detail.

                   I would suggest that very high resolutions images be treated carefully whether or not you move them to the control of a separate database file. (Though images for hard copy publication typically require far higher resolution than those to publish to the web.)

                   A single artwork record can link to a table of multiple image records--each with a different container field that references a different artwork file for the same artwork--providing support for both high and low resolution images. And then you can limit access to the records for Hi Res images to just those users or tasks that require it. Those users that are currently just browsing a catalog of images can be presented with much smaller "thumbnails" of the images.

                   Given that you have FileMaker 12, you can use externally stored container fields to hold references to your image files and you can use the GetThumbnail function to produce lower res copies of existing images if you have the need for such in your database.

              • 4. Re: Advice on how to OR not to build another database with portal
                ahutler

                     Could you explain this more?

                     "Given that you have FileMaker 12, you can use externally stored container fields to hold references to your image files and you can use the GetThumbnail function to produce lower res copies of existing images if you have the need for such in your database."

                      

                     If I am understanding the above statement, we wouldn't need a new db/table, but a new layout that would hold thumbnail reference images to the large jpegs/tiffs via the GetTumbnail function?

                • 5. Re: Advice on how to OR not to build another database with portal
                  philmodjunk

                       Not quite. I don't know how your current database is designed so specific descriptions of what to do may not fit your actual database.

                       You can set up this data model:

                       Artworks------<Images

                       Artworks::__pkArtworkID = Images::_fkArtworkID

                       A container field in Images can store a reference (via External Storage) to single image file for that artwork, but you can 2, 3 or even more such Image records and the image resolution of the file referenced in each such image record can be different. An added field in Images can identify whether the image is hi res or lo res. Then you can use filtered portals or added relationships that only match to one type of image or another to selectively display either a hi res or lo res image for that artwork.

                       GetThumbNail is a function that you can use in a script to generate lower res copies of existing image files if you need to be able to do that.

                  • 6. Re: Advice on how to OR not to build another database with portal
                    ahutler

                         Would it be possible to store the jpegs/tiffs as a refernce in the container field in this 'High Res Image' layout? Would THAT cut down on loading time, storage, etc? Would the user be able to see an the image/jpeg/tiff in the layout if stored as a reference?

                          

                         IF stored as a reference is it possible to export image (using a button) to the user's desktop?

                          

                          

                    • 7. Re: Advice on how to OR not to build another database with portal
                      philmodjunk

                           I would recommend that all of your images, Hi and Lo res, be either inserted "by reference" or inserted into a container field with external storage specified.

                           Either method stores only a reference to the file in the container field.

                      • 8. Re: Advice on how to OR not to build another database with portal
                        ahutler

                             when you say "external storage specified", do you mean store images elsewhere on my computer?

                             which I do, but I have never checked the "store as a reference" option when placing images in the db. (my process is: right click-insert image in the specified container field-and browse untill i find my image in my images folder).

                              

                             If is start inserting images "by reference" can I still create a button that has a script on it so the user can download that image on to their desktop?

                              

                              

                        • 9. Re: Advice on how to OR not to build another database with portal
                          philmodjunk

                               External Storage is a new option first introduced in FileMaker 12. It allows for some simpler options for dealing with referenced image files in a container. I suggest that you look up this term in FileMaker help to learn more about it than I care to copy and paste from the help system to this forum.

                               "store a reference" is the original option for only inserting the file path to a file located elsewhere (can be anywhere on your network).

                               External storage is different and is not used with that check box selected when inserting images. In it, files are copied from the container field into which it was inserted to a specified storage location and then the container field is updated to replace that copy in the container field with a reference to the copy now placed in the specified storage location.

                               

                                    which I do, but I have never checked the "store as a reference" option when placing images in the db.

                               Then your current design does NOT store a reference to those image files. Instead, you have a physical copy of the file stored inside the database. This is NOT what I recommend for a database for managing large numbers of images.