Get in the ring: Natural Keys vs. Surrogate Keys ... The identification of business objects and the identifier in the persistence store are concepts of different concern: on the object side there is the need to identify a domain entity, while in the persistence layer the focus is on retrieving and storing data efficiently, by normalization over artificial Surrogate Keys. Using the database specific identification in the business layer means coupling this layer to a internal and technical usage of Surrogate Keys. In many projects the Surrogate Key is propagated from the database to the business layer and also to the front-end. By doing so a technical detail - the identification technique of a certain persistence store - is adopted in all further layers, thus the Surrogate Key gains business meaning and the persistence layer is not decoupled from the others anymore.

BTW another original paper: "A Relational Model of Data for Large Shared Data Banks"

In this paper Codd explains the benefit of the relational model in a Mainframe World over a tree based navigational model wich prevailed in the late 60theens. The arguments presented touch me because I worked two years with JCR a pure tree based naivgational model. Its easy to see that a nonhierarchical model in a multi-application environment is superior. But probably it is far more maintainable also in an App-DB world.