I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
I thought owned types were already implement by EFCore as fields of the owner.
Why are you overriding that and creating a separate table?
By default, you wouldn't need so much customization code.
For example, EFCore would have created the fields Person.Address_Street_City_Name, Person.Street_City_State_Country_Initials, Person.Street_Street_City_State_Country_Name, and so on, without requiring a join and a separate table, and foreign keys, etc.
That should be faster to query and btw, EFCore takes care of creating the shadow identities behind the scenes in this case, and you don't need to worry about them, because you don't need them, they're just there so that EFCore can keep track of the object to database mapping.
You should do what is most performant not what is "easiest to read".
Your context hasn't been stated – but in general for databases optimize for the machine, not the human. That's what OO is for.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I thought owned types were already implement by EFCore as fields of the owner.
Why are you overriding that and creating a separate table?
By default, you wouldn't need so much customization code.
For example, EFCore would have created the fields Person.Address_Street_City_Name, Person.Street_City_State_Country_Initials, Person.Street_Street_City_State_Country_Name, and so on, without requiring a join and a separate table, and foreign keys, etc.
That should be faster to query and btw, EFCore takes care of creating the shadow identities behind the scenes in this case, and you don't need to worry about them, because you don't need them, they're just there so that EFCore can keep track of the object to database mapping.
Hi @brokenthorn , thanks for the comment!
It's a trade-off between "JOIN" and "Let the table grow as the number of value objects grows".
In this case, I think those depend on the context.
Remember tables are for computers not humans.
You should do what is most performant not what is "easiest to read".
Your context hasn't been stated – but in general for databases optimize for the machine, not the human. That's what OO is for.