>That is surprising to me. Microsoft's Northwind database had the same design flaw, so maybe SAP simply wanted to be "feature-by-feature competitive." Actually, Northwind also had a combined key somewhere in the design (a key consisting of two concatenated columns.)

SAP was around long before MS's Northwind. SAP goes back to the 80's on a mainframe.


>The problem with "natural" keys like this is that if you ever allow the end user to change this value through the user interface (and PO number probably should be editable for reasonable flexibility), your system needs to propagate any changes to PO numbers across all of the dependent (child) tables. To make the change safe, you have to wrap the entire change chain in a transaction just in case the propagation is unsuccessful in which case you need to roll back all of the changes so far. It is a very messy way of doing it, especially since surrogate ("meaningless") keys make this type of change completely trivial (assuming that you have normalized your data design so that PO number appears only once in only one table.)

Once a record is created the key (in the above the PO number) cannot be changed - it is fixed. Also, the user does not specify the PO number -- it is auto-generated by SAP (as well as all other key values). It is only the configuration of the number ranges that is permitted and is done at the start of an implementation. Actually, every record in SAP has multiple keys (columns) - there is a client key as well. This key allows for running multiple copies of SAP on the same database (in one instance). All customers will have multiple clients configured and this is a recommended practice by SAP. The multiple clients are typically at the development level and quality/test level. There is typically only one production client (although the customer I am currently working with has two production clients).

>Why would SAP do this is beyond me.

In over 30 years never had a problem... works very well!!