I've seen advice that strongly recommends people stick with the serial ID system provided by Filemaker.

However, the reason I am looking for an alternative ID system is the difficulty in trying to recall a number for a certain artist or a concert.

I've been thinking of "creating" a unique ID for one each Artist in one table; another unique ID for each Concert in another table (and possibly a unique ID for each piece of Repertoire in another table).

For instance I'm playing around with this idea:

S1 2011-12-25

This would mean the "Season 1 December 25th 2011 concert". It is easier for me to generate, recall, input this ID than "34" for a certain concert I am looking for; what I'm doing right now is having to write print/write out Artists' names and then write out the serial number for them so I can recall it.

I'm trying to figure out a code for each other artist. But if the majority of the people here recommend against this path I'll stop!

Perhaps there is a way to recall the serial ID in the intermediate table that I am producing simply by search in the Name or Title field?

I have limited experience with Filemaker or with database principles. I would appreciate your more experienced advice.

After doing a little more research on the net, I now understand the merits of a simple numerical serial ID system. Though easier for me to recall, the "descriptive" ID can lead to duplicates or unwieldy IDs. Furthermore I have access to very little data other than first name, last name, and instrument; and thus not many resources to distinguish between two similar names.

I guess I will have to try to find a way to easily call up the ID of a certain person.

There's really no need to have the unique ID part of the user interface. You can find records by searching for lastname =Doe, firstname= John, concertdate = 1/1/12, or whatever descriptive search criteria you may wish to use. You WANT the id numbers to be meaningless, and therefore not useful for searching. "Pay no attention to the ID number behind the curtain."

Think of it this way: when you search for a song on your iPod, you don't search by an ID number, although one is certainly used by the software to find your song.

Most of the advice you'll find online about IDs is referring to primary keys, used by the database to tell which record is which. As doughemi points out, users don't have to deal with that ID, but that doesn't mean an ID that isn't the primary key isn't useful anyway. I frequently use non-primary-key IDs for invoice numbers, for example. Perhaps you can find something useful in these discussions:

http://fmforums.com/forum/topic/81617-the-user-interface-design-of-id-numbers/

http://fmforums.com/forum/topic/81562-to-number-subgroups/page__fromsearch__1

For instance I'm playing around with this idea:

S1 2011-12-25

This would mean the "Season 1 December 25th 2011 concert".

It would also mean that no other concert can take place on December 25, 2011 (I presume the season is a function of date, and therefore redundant?). And if that's true, you will find that concert by entering the date - no fancy codes required.

I have access to very little data other than first name, last name, and instrument; and thus not many resources to distinguish between two similar names.

Now, that is a problem. But how is a unique code going to help here? So we have John Smith, a flute player with a code of "JohSmiFlu" and then another John Smith, also a flute player - but this one has a a code of "JohSmiFluB". How I am going to tell which one is which?