This type of question raises all sorts of questions regarding exactly what it is you’re trying to model and what the longer-term on-going data requires.
What you need to determine as part of your “system requirements” are the overall objectives of this system. Are you just replacing some “pen and paper” forms? Or is this part of (potentially) a larger system? What are you looking to do with this data after collecting it?
Before creating any code, you should have a solid understanding of the data being managed - the entities (Person, Application, Property), their relationships with each other, and how those relationships are managed over time.
(Now, that’s not to say that these requirements can’t change - they absolutely can. Nothing is etched in stone. But you do need to know what your starting position is going to be.)
Just to give you an idea of some of the questions raised -
Do you want to be able to have the same person able to apply for multiple properties?
- Or can one individual only apply for one property?
- Or can they only apply for one property at a time?
(in other words, can they apply for property “X”, and then at a later time apply for property “Y”?)
If a person applies for property “X” and then later applies for property “Y”, are you looking to reuse the existing Person for that person, or create a new instance for that application?
Different answers to these questions are likely to yield different model structures.
(Side note: You’ve defined your
Application model using a singular name, which is good, but you’ve got
Properties defined as a plural. Suggest you change it to Property.)