3 Replies Latest reply on Sep 18, 2009 9:52 AM by AndyCohen

    Lots of tables or one table with lots of TOs? Opinions please!

    AndyCohen

      Title

      Lots of tables or one table with lots of TOs? Opinions please!

      Post

      Puting all the data into ONE table then dividing the table up into TOs using a relation as a filter has advantages....  not the issue...

      I have a database which retains graphic elements shown in containers.  Which do YOU think would PERFORM better...   one table and divide up into TOs or seperate tables???   There's likely to be about 40 tables if I divide into tables. Using a relation as a filter has had a performance hit in past applications in which I have used just 1 table.

        • 1. Re: Lots of tables or one table with lots of TOs? Opinions please!
          TSGal

          Andychn:

           

          Thank you for your post.

           

          If there is no reason to put the information into separate tables, then don't!  It is much easier for FileMaker to read information from the current table then to perform a lookup across the other tables for information.  If some information is not necessary to be displayed on a particular layout, then omit it, and put it in another layout.

           

          However, if you have three or four phone fields, or several container fields, you may want to consider putting that information in a separate table.  That way, one user may have one phone number, while another has four or five phone numbers, or one user may not have anything in a Container field while another has ten images.

           

          In other words, if you have redundant data, put that into a separate table and reference it. 

           

          TSGal

          FileMaker, Inc.

          • 2. Re: Lots of tables or one table with lots of TOs? Opinions please!
            mrvodka
              

            This would also be a good time to mention something from Jon Thatcher's under the hood session at DevCon. One2One relationship are beneficial when it comes to large data in fields that are rarely used. When in a served enviroment, FileMaker will download all the data from EACH non-container field of the entire table even if it only on field is referenced on the layout, tab panel, or portal.

             

            Therefore, if you have large blocks of information such as a log field, this should be in its own table, even if you want to keep it in one field for some reason, and should be using form view.

            • 3. Re: Lots of tables or one table with lots of TOs? Opinions please!
              AndyCohen
                

              Actually there usually is a good reason to split data into seperate tables when the relationship to the superordinate table is identicle. Typically its an issue of decentralization of the data for any of dozens of reasons. 

              Assuming the data are alphanumeric I can see why one would want it all in one table from a performance standpoint.  It does go faster... alot faster...  Unfortunately in the case of the above the app that intiated the question is using graphics in a container...:smileysad:

              It's my experience there's not much one can do to speed up an app which uses containers to show lots of graphics.