I think in relational databases (=in standard database world) foreign key always should point to the primary key.
Maybe PostgreSQL allows such something, maybe PostgreSQL (or other database) allows a construction of primary key from more as one fields, and so on, but I think it is not good idea to use such 'feature'. Web2py is more strict and in this case I think this is good (one reason, why I have chosen web2py). What you wait from such foreign key? I think foreign keys have only 2 goals: 1) if record with some primary key is to be deleted, records with connected foreign keys should be automatically delete (Cascade integrity) or cleared (SetNull integrity). 2) foreign key together with associated primary key can help automatically prepare join expressions, if we use DAL(database abstraction layer) instead of raw SQL. To previous 2 points I think, Web2py has problems or things which can be improved in the future: 1) SetNull integrity is not supported yet 2) join expressions aren't automatically created based on the DAL definition there is a third problem here, 3) Web2py turns on references support immediately after each table definition (correct solution is: after all tables are defined). From that reason you never can implement more complex database models in web2py. So we can see, using of 'reference..' field type give us no advantage at this time. You can use 'integer' type instead. The only thing you need to program is deleting integrity at application level. So I think using of 'integer' for the foreign key is solution for your problem. Or, 2-nd possible solution, you can have, if you will re-evaluated article.journal_id to point to journal.id. It's possible, because journal.id is unique of course, and journal.ouid should be unique too (because otherwise you have serious problems). Such re-evelauting is same, as you can find in Web2py sources, where replication is handled. See "CSV and Remote Database Synchronization" in 6-th chapter of Web2py book. uuid there is in similar role as your journal.ouid, but foreign key in this example always point to .id field.
