[eluser]OverZealous[/eluser]
You can try to eliminate the ID column, and then set up the primary key on all remaining relationship columns (usually there will just be two). That should work. Again, DMZ doesn't use the id column for anything.
The issue you described with saving it as NULL then updating it primarily shows up with in-table foreign keys. Currently there is no easy way around this, but you could try making the FK optionally NULL (for example, in PostGreSQL you can add ON DELETE SET NULL to the FK definition).
The number one reason I haven't bothered with FK restraints id the fact that it can slow down inserts and updates, and provides no optimization benefits (at least on PostGreSQL) for queries. Since I only write to the DB through DMZ, and I always use transactions, there is very little possibility for corruption. The big exception to that would be some kind of weird asynchronous update from multiple users, but large transaction blocks should help reduce that risk.
However, I am aware that this is bad database design, as the FK rules provide an extremely low-level check to make sure you don't break anything...
