>>>I'm considering a certain Business Object tool that I've been reviewing, but I may have a potential problem with my existing data tables as far as the PK/FK matter between my Parent tables and the related Child tables...
>>>
>>>The issue is that BO tool under consideration requires Integer PKs, and many of my tables use String PK on the parent and String FK on the child records pointing back to the parent. For instance, on my Job parent table, a typical JobNo string PK might be "UR-56342A" or "4033X-01", "4033X-02" etc., and the child JobItems table records will have a String FK JobNo field also that contains the same value. Although there is an AutoInc integer (ipkey) assigned to each parent record, I generally navigate the forms and map the children by way of the string JobNo field. It would be easy to add and ifkey field to the child tables and update it to match the parent ipkey. However, I must allow the users to enter the String value, and then I'll have to do an intermeditate lookup to get the real ipkey value. Is this a common scenario?
>>>
>>>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. I believe I can still use this tool and work around the matter with some reasonable coding, since my current home-grown BO handles this already, and I have seen the source code, and I believe I can make the necessary adjustments and move right along. The question is... should I change my data PK/FK approach for a long term benefit, or make the necessary mods to the BO classes to handle the Strings?
>>
>>Others have probably already said this but you really should have a non-meaningful PK, for which Integer is fine. (Except for huge tables where you might need a GUID, which is a slight performance hit). That way you don't have to worry about uniqueness at all. Set it to be an autoincrementing field and forget about it.
>
>Non-meaningful PK is fine, and I can see the place for it. I'm now just wanting to confirm that once that is in place in the schema, that there is still a place for working off, AND STORING, a "meaningful" String (aka Surrogate Key) from a UI screen for us humans to use. Realizing that, once that is entered by the user, behind the scenes I will do a lookup on the human-friendlty String value to resolve the Integer PK, and then use that for the rest of the transaction.

This:

my Job parent table, a typical JobNo string PK might be "UR-56342A" or "4033X-01", "4033X-02" etc., and the child JobItems table records will have a String FK JobNo field also that contains the same value. Although there is an AutoInc integer (ipkey) assigned to each parent record, I generally navigate the forms and map the children by way of the string JobNo field

is fine. Except the mapping of children should be done by the hidden Pk/Fk. It is recommended that when updating or adding or linking parent and child records, it actually be done via the hidden key fields in tables. Hence your search for the typed JobNo and get the PK for the record and then go from there behind the scenes would work and I've seen it done that way. As long as the JobNo field on the parent table set to not allow duplicates?

Are child records for one job ever moved to a different job (parent)?