I work on programming Database Apps at work, and when I designed my own Orchid App (PC based) I did put one in as an identifier across all the orchids. I basically used an incrementing number for each orchid, which was the field used to link multiple records, across various tables, relating to the same orchid together.
It's good design to use such a number (a GUID or similar if not an incrementing number) so that if the user wants to change the name of the item (in this case the name of the orchid) you don't have to change all the associated records to still be able to find them. (For example the RHS change the name and the user wants to update their records, or in my case, more often than I would like, I realise I've spelt a name wrong and want to correct it.)
That having been said, whether or not such a number is shown to the user or just a hidden part of the structure of the DB is another matter. If you use a GUID it will be nonsense to the user, so why show it (I do in one case in a project at work, but there are reasons for that). Generally speaking the user doesn't need to see the number given to the item (orchid) and don't need to understand it if it's a GUID.
In my orchid app I show it, however the only real use for it is because my UI is poor and only half written, and I often have to dive directly into the DB to tweak some data because I don't have the functionality in the UI. (I don't expect I will ever finish it to a standard I could sell it like you do... it's just a pet project I occasionally fiddle with, and I've got working
just well enough for my own use.)
Anyway, because of that being able to see the Orchid number is useful. But if I had a full working UI and didn't dive into the back-end DB then I can't see why it would be useful to see. I used to write the number on the tags when I first started out, but dropped that as it really wasn't any use.
I do also have a number
after the orchid name as people have suggested above. So if there are multiple plants with the same name they get a number each, so I can see from the tag which individual it is in the app. This
is useful, almost essential in a large collection, so would be well worth adding if you don't have one.
P.S. After saying about having a unique number to tie records together so names can easily be changed, actually changing a name is one of the things my UI can't do. Have to dive into the back-end DB to do that... but at least I only have to do it in one place