1 Reply Latest reply on Mar 4, 2013 9:58 AM by philmodjunk

    Proper Table Structuring of a Technical Publication.

    PhillipFountain

      Title

      Proper Table Structuring of a Technical Publication.

      Post

            

                I have a technical publication that needs to be presented in a FileMaker table in the following format:

                 

                5.0 - Training and Proficiency

                5.1 - Training Programs

                5.1.3 - Do the training programs include the following:

                5.1.3.a - for flight crew members:

                5.1.3.a.i - initial and annual aircraft type and systems training

                5.1.3.a.i.A - emergency procedures training

                 

                I’m looking for the best method for structuring the table. Is it best for each of element to have a separate record with one field for the numbering system and another field for the text? Or, a field for each of the numbered elements such as 5.1.3 and 5.1.3.a.

                The 5.0 and 5.1 elements are used to identify the sections of the technical publication, no additional field information is needed in the record. The only purpose of these two items is to orientate the user to the database section and to be used for Finding a desired group or subgroup of records.

                All records with numbers containing three or more elements will have other fields that may require information.

                Would it be best to have two tables, one that contains fields for the 5.0 and 5.1 numbers with the associated text fields and the other table containing the detailed information requiring the additional fields?

                The last thing I need to know is how to structure the fields for the relationships?

            

        • 1. Re: Proper Table Structuring of a Technical Publication.
          philmodjunk

               This is a case where you can do both. You can set up individual fields for the individual values separated by periods in your id code and yet a calculation field can combine all the indifidual values intot a single text string. Separate fields will allow you to effectively sort your records in ways that may or may not be possible if you just sort on a single field. Numeric values in text fields won't sort correctly unless the number of digits are exactly the same, so trying to sort on a single text will fail if you have a section numbers that require two digits. (10 will sort to be before 2 when the two values are text values).

               

                    The last thing I need to know is how to structure the fields for the relationships?

               And what relationships are those? The needs of the relationships specified by your data model will determine how to structure any fields you use in relationships.