The issue with your EDIT 1 comes from these facts:
- The
Request
table does have a unique constraint over the column "ResponseId". I.e. each row must have different value - The
Requests
stored without reference to Response do haveNULL
instead of any value... all of them. And that breaks the above requirement to have each row unique
Solution in this case would be to remove the unique key on the DB level from the ResponseId
column. Because this is what we need (Request without Response). I.e. few concurrent NULL values in ReponseId should be allowed.
But what is a bit confusing me, is the naming: Reponse/Request
It seems to me, that Request (from my web development experience) is the trigger, the first one. And if all goes ok, there is a Response sent back. Should not your mapping be inversed? That the Response table contains the RequestId?
I've seen this statement in the question:
My Request entity should be able to exist without a Response entity, and vice versa my Response entity should be able to exist without a Request
Well, so ... let's assume that: the Response
can NOT live without the Request
... then your mapping (but inversed) should work even with the Unique key constraing.
And what is even more important, then the pure one-to-one
mapping will work, because these two can share the Primary key (generated by Request, consumed by Response)