>>
>>This is 4 of a number of reasons to favor surrogate keys. There are many other reasons too.
>
>>WOW... You seem to know a little about this stuff. I think I followed most of what you said. Can you help me apply this to a common struggle I have with the following...
>
>A purchase order parent table with a character keyfield called "po_num", and a line-item child table with a "po_num" keyfield linking one or more child records to a single parent record. Now then, if I need a method of re-arranging the child records (like if a user wants to insert a line-item between the 2nd and 3rd line-item) I have always used an numeric field in the child table with a compound index of "po_num+item_no" and automatically assigned the "item_no" value in 10 increments (like old BASIC line numbering). This way, the user can add line-item 25 between line-item 20 and 30. If you auto-assign the "item_no" value in increments of 1, there is no simple "insert between" scheme.
>
>Is there a better way to handle this data model?


Easy. You create a view of the line items with order by lineno and tey will always be ordered by lineno. If change lineno the ordr will change and since lineno has no bearing in linking to the header table (you are using surrogate keys, aren't you) you are free to do anything you want with lineno.
Peter