8 Replies Latest reply on Mar 1, 2009 3:24 PM by macbuz

    Multiple 'First Name' (i.e.) Fields

    macbuz

      Title

      Multiple 'First Name' (i.e.) Fields

      Post

      Simple question probably simple answer. If I have a field 'First Name' in a Customers table and also in an employees table, am I looking for trouble? Should they be annotated such as 'C First Name' and 'E First Name' perhaps? Is there some other convention/method that I should be aware of?

       

      Thank you. 

        • 1. Re: Multiple 'First Name' (i.e.) Fields
          davidhead
            

          I can see no problems when they are in separate tables. Whenever you refer to the field remotely (not from within the table) it will be referenced using a table occurrence name as well as the field name. So it should be obvious which first name field is being referred to.

           

          Another more interesting question is why do you have separate customers and employees?

          What happens when an employee becomes a customer?

          • 2. Re: Multiple 'First Name' (i.e.) Fields
            macbuz
              

            uLearnIT wrote:

            Another more interesting question is why do you have separate customers and employees?

            What happens when an employee becomes a customer?


             

             

             

            Thank you David. Was doing some voracious reading last night and saw in a Tip regarding automatic number formating (SSN's and Phone #'s) where tablename::fieldname was being referenced, gave me a clue to the answer.


            Regarding your comment, well, fair enough. Why do I? It seemed from a learners point that it was logical somehow. Coming from the construction industry I tend to 'pigeonhole' stuff. My MO here is to be able to develop an interface that I can use to account for and bill for labor, materials, sub-contractors, etc. Seemed tables for each 'heading' is what I should do.


            In the end I intend FMP to produce the totals to invoice customers, as well as produce totals for payroll bookkeeping. I'll have a mix of Empl's A, B and C working on Cust's D, E, F. I'll need A/DEF, B/DEF, C/DEF, D/ABC, E/ABC, F/ABC ... in other words for payroll I need Emp A/DEF and for invoicing Cust D/ABC.


            The answer to this question may be the clue I need to 'see' your question. >> 90% of my customers live outside our local area hence they have addresses where they live as well as job site addresses where I'm working on their 2nd home (vacation home). Don't these need to be defined differently?


            Thank you for your time.


            P.S. Terminology! File > Manage > Database shows I have 4 'Tables' (so far). However those 'Tables' are referred to as 'Layouts' in my 'Status Bar'. Do I have terminology problem as well? Thank you. 


            • 3. Re: Multiple 'First Name' (i.e.) Fields
              comment_1
                

              macbuz wrote:

              File > Manage > Database shows I have 4 'Tables' (so far). However those 'Tables' are referred to as 'Layouts' in my 'Status Bar'. Do I have terminology problem as well?


              Layouts are not tables. You have 4 tables (sometimes called 'base tables') - that's where the data is kept. Each table can have a number of table occurrences (TO's) on the graph - this determines the context of the data. And each TO can have a number of layouts.


              • 4. Re: Multiple 'First Name' (i.e.) Fields
                macbuz
                  

                Please bear with me here. Reading your reply I hesitate at 'on the graph'. Does 'the graph' refer to the Layouts pop up? and so my TO's are various layouts of my named Tables?

                 

                I noticed a Table w/o fields is not listed in the Layouts. Makes me think once I add fields it becomes a TO or Layout 1 of that table.

                 

                Getting the terminology really helps. Thank you. 

                • 5. Re: Multiple 'First Name' (i.e.) Fields
                  Jade
                    

                  macbuz wrote:

                  Does 'the graph' refer to the Layouts pop up? and so my TO's are various layouts of my named Tables?

                   


                  I think Comment was referring the the Relationship Diagram that can be displayed from: Manage>Database…Relationships.  This shows graphically the tables that you have created and allows you to connect key fields from one table to another thereby defining relationships between tables.
                  You will see a button at the bottom of this 'graph' (++).  If you select one of your 4 tables and then click this button, FMP creates a second instance (or TO) of the table.  Think of this as an alias or duplicate.  The advantage is that you can use it to create different relationships.
                  This is perhaps a bad example but imagine for a moment using this mechanism to relate: i) customers to invoices and ii) employees to payroll using just one table for 'people'.  Obvioulsy, you will need different layouts (i.e. forms) to enter and handle the two different scenarios.  One layout can be linked to the original table while another can be linked to its TO.  The bottom line is that you have fewer fields and data stored in your database since you have combined the customers and employees into one table.  You have also reduced the possibility of duplication of data (e.g. when an employee becomes a customer).
                  Hope this helps… 

                   


                  • 6. Re: Multiple 'First Name' (i.e.) Fields
                    comment_1
                       The graph = the relationships graph (third tab in Manage Database).

                    I think what may be confusing you is that when you create a table, Filemaker automatically creates a TO of the table and places it on the RG, and it also automatically creates a layout for this TO. Both the TO and layout are initially named the same as the base table - but they are not the base table: you can rename the TO and/or the layout, or even delete them - all without affecting the base table.


                    BTW, there is nothing inherently wrong with keeping separate tables for Customers and Employees. It all depends on your business rules. In some applications, customers and employees are treated similarly enough as to form a single entity. In others, they have nothing in common, except that they both happen to be about people. And of course, there are many situations that fall somewhere in-between the two extremes, and pose a challenge for the developer.


                    • 7. Re: Multiple 'First Name' (i.e.) Fields
                      macbuz
                        

                      Yes this helps. I understand the graph refers to the Relationships tab of Manage Database. Also understand that a TO doubles, alias' or otherwise makes a duplicate of a Table in the graph.

                       

                      I'm working through a pile of videos done by John Mark Osborn (just the free ones for now) and it's apparent I need to back up a bit and perhaps rethink my 'little' project here. From the few threads I have here and what I'm learning from the videos, my structure may leave something to be desired along with naming conventions and not sure what else at this point. (Thinking if I continued construction of the DB I would eventually find myself backing up again)

                       

                      Thank you very much!!

                       

                      P.S. Why do my posts have so much white space below them and other's don't? :smileysurprised:

                      • 8. Re: Multiple 'First Name' (i.e.) Fields
                        macbuz
                          

                        Thank you too comment - this helps as well!! Seems we were composing at like times. I think I may be getting my head around understanding Tables / TO's / Layouts. Tables are the only place fields exist and are created, TO in RG 'images' the Table and the Layout is only the first Layout of that Table. Subsequent Layouts still work from the Table/Fields listed.

                         

                        It's a patient/tolerant lot here!  Thank you.