I\'ve factored out common attributes from two classes into an abstract base class, however I have another model that needs to reference either one of those classes. It\'s no
My gut would be to suggest removing the abstract modifier on the base class. You'll get the same model structure, but Answer will be it's own table. The downside of this is that if these are large tables and/or your queries are complex, queries against it could be noticeably slower.
Alternatively, you could keep your models as is, but replace the ForeignKey to Answer with a GenericForeignKey. What you lose in the syntactic sugar of model inheritance, you gain a bit in query speed.
I don't believe it's possible to reference an abstract base model by ForeignKey (or anything functionally the same).
A generic relation seems to be the solution. But it will complicate things even further.
It seems to me; your model structure is already more complex than necessary. I would simply merge all three Answer
models into one. This way:
Answer_Risk
would work without modification.resident
to None (NULL) in case of an Answer_A
.resident == None
. (in other words; same functionality)One more thing; are your answers likely to have more than one risk? If they'll have none or one risk you should consider following alternative implementations:
Answer
class.My main concern is neither database structure nor performance (although these changes should improve performance) but code maintainability.