If you want to use the ORM's features for related models, you should create a relationship (one-to-one in this case) between the two models. In one of the models you can (and should) then omit the special_id
reference.
You can use the foreign key as a primary key in FooDetail
, and if you keep special_id
as a primary key in Foo
, you'll be saving exactly the same type and amount of columns and data as in your example (namely one column in each that contains the relevant special_id
).
What you get though is the benefit of a relationship and enforced integrity.
The only difference is that when you introduce a new special_id
, you have to create Foo
first to be able to point to it in FooDetail
– hardly a big price to pay.
If you get a warning on setting the reference field to Foo
to be the primary key then it might be that you defined it as a ForeignKey
. You should define the field as a OneToOneField
since you're dealing with a one-to-one relationship as noted above. The field is still technically a foreign key (= reference to the primary key of a row in another table) which is why I used this term; but it has a unique constraint that allows it to be used as a primary key.