>>If the String PK/FK approach is really ugly and just a BAD idea, I could use this as an opportunity to refactor over to an Integer based approach.
>
>Using strings as a PK is not ugly. In fact, in many projects I use GUIDs instead of integer primary keys. GUIDs do have many advantages over integers. I wouldn't, though, refactor a system to use GUIDs if it's currently integer values unless I have a strong business case.
>
>However, from what I understand is that you are ignoring the PK in your tables and instead are using other fields to link data, because those fields are the fields that the user enters. That's something I'd avoid.


Ok, so I can refactor to link PK/FK using Integers instead of strings, but please confirm that it is valid/reasonable to let a user enter a string into a lookup box that matches a string-based PO# or JobNo reference, like "MS3424C" or "UR-23423A" and then I have to do an intermediate lookup to search for the corresponding Integer PK. I *MUST* allow then to create these strings when adding new Parent records, and I *must* allow them to re-enter the values in the future to navigate back to these records. The whole domain operates off of thesse Strings. They are like a language in some ways. They mean things that people can decipher just by seing them. They need these String values, and cannot just use integers like 3423232. But I know I can accept strings, store strings, but also assign ints and do int lookups. Surely this is a very common thing.