8 Replies Latest reply on Aug 2, 2015 5:22 PM by isamudysan

    unique IDs for different models

    isamudysan

      my question is this:  is it possible to have separate unique IDs for several different models in unique ID field? for example the table below:

       

      Unique IDModel
      mID1-0001Model 1
      mID1-0002Model 1
      mID2-0001Model 2
      mID2-0002Model 2
      mID3-0001Model 3
      mID3-0002

      Model 3

       

      if one can have multiple different IDs, how would one go about implementing it?  can/should it be done via scripts or calculations?

       

      thank you and i greatly your insights and thoughts.

      toufue

        • 1. Re: unique IDs for different models
          mark_scott

          Hi toufue,

           

          You're probably going to have to explain a lot more about what you're trying to accomplish.  What do the Unique IDs represent?  The Models?  What is the entity represented in the table?  (To answer that one, answer the question "what does each single row in the table represent?".)  Right now, I'm afraid it's all too vague for anyone to chime in with a definitive reply.

           

          Depending on those answers, there's a chance you'll need to divide (normalize) it into two separate tables.

           

          hth,

           

          Mark

          • 2. Re: unique IDs for different models
            keywords

            A well established set of FM principles is that:

            1.     every record in every table should have a unique ID

            2.     that ID should be, from the user point of view, meaningless data

            3.     that ID is the field you use for FM purposes only, to build relationships

            4.     any data you want to be meaningful to users—including unique part numbers (IDs if you will)—should be entirely separate from the unique ID that FM uses (see 1 to 3 above).

             

            If you want the model ID you appear to be demonstrating in your very limited post to be meaningful, go ahead and make it using a calc based on other field data, as you appear to be thinking (model 1 = mID1–xxxx). Just don't be thinking you will also use this as you FM unique record identifier, as it is bound to fail you at some point.

            • 3. Re: unique IDs for different models
              dsvail

              ID =  auto enter serial number ( next value 0001)  for your relationships

              Model = model name

              modelAbbr = user input or calc from the model name

               

              user viewable model ID =  modelAbbr & ID

              • 4. Re: unique IDs for different models
                mark_scott

                Absolutely agree with keywords that, if Unique ID is meant to serve as the table's primary key, then a separate field that is not exposed to users is preferable and considerably more robust.  A lot of (most?) developers are using a UUID for that, either FM's native Get ( UUID) function or any of several custom functions that provide one.  (For large tables, a strictly numeric version, which a custom function can provide, may yield a small performance benefit; most solutions, however, are unlikely to see that benefit in practice.)

                 

                Do you track any other attributes of each Model (or are you at all likely to do so in the future)?  If so, then Model should probably be a separate table with its own primary key — again, a robust key such as a UUID, rather than "Model1," etc. — and represented in your table here by a matching foreign key.  But I'm reading into your description well beyond what you've provided, and possibly incorrectly.

                 

                hth,

                 

                Mark

                • 5. Re: unique IDs for different models
                  isamudysan

                  mark and keywords you both are correct.  i'm thinking that that the UUID can be a meaningful use to users as an identifier; however, after reading both replies, i have to agree with what you both are alluding to.  UUID cannot be used in the sense of keeping track of the different models of units, rather the UUIDs are useful for relationships between tables.  i was thinking that UUID may be able in some way to be used as a tracking ID number of some sort.  i greatly appreciate you both for really clarifying that up for me.

                   

                  the next question would be: how would i go about adding an ID (text field) that can be used like an asset tag for the different models (which will be meaningful)? as stated in the OP, the the numbers will have to increment by 1.

                   

                  i have never dealt with something like this before as it popped in my mind regarding these different models (of phones lol).

                   

                  thanks.

                  • 6. Re: unique IDs for different models
                    keywords

                    Try devising a calculation that concatenates data from other fields. See the attached demo for the concept.

                    • 7. Re: unique IDs for different models
                      electon

                      Have a look at this example.

                      I think what you're trying to do is create increments for grouped sets of data.

                      Therefore model should ideally be a separate entity, I gave it a separate table.

                       

                      Is the field you're trying to calculate like an SKU = Stock Keeping Unit?

                       

                      I was trying to write a lengthy post about uniqueness similarities between UUID and SKU but it's too complicated.

                      Let me know what you think.

                      • 8. Re: unique IDs for different models
                        isamudysan

                        thank you keywords and electon, and, of course, everyone that replied.  i apologize for not getting back to you all. work has been quite busy.  being a trainer, we've been getting a lot of new faces. not just that, but vendor visits and audits, well, busy...lol.

                         

                        appreciate all your replies, again. keywords and electon, i'll look at both of your files and see where i'll go from there. appreciate the sample files a lot.