[ACCEPTED]-Entity Framework inheritance: TPT, TPH or none?-inheritance
When considering how to represent inheritance 32 in the database, you need to consider a 31 few things.
If you have many different sub 30 classes you can have a lot of extra joins 29 in queries involving those more complex 28 types which can hurt performance. One big 27 advantage of TPH is that you query one table 26 for all types in the hierarchy and this 25 is a boon for performance, particularly 24 for larger hierarchies. For this reason 23 i tend to favour that approach in most scenarioes
However, TPH 22 means that you can no longer have NOT NULL fields 21 for sub types as all fields for all types 20 are in a single table, pushing the responsibility 19 for data integrity towards your application. Although 18 this may sound horrible in practice i haven't 17 found this to be too big a restriction.
However 16 i would tend to use TPT if there were a 15 lot of fields for each type and that the 14 number of types in the hierarchy was likely 13 to be small, meaning that performance was 12 not so much of an issue with the joins, and 11 you get better data integrity.
Note that 10 one of the advantages of EF and other ORMs 9 is that you can change your mind down the 8 track without impacting your application 7 so the decision doesn't need to be completely 6 carved in stone.
In your example, it doesn't 5 appear to have an inheritance relationship, it 4 looks like a one to many from the address 3 type to the addresses
This would be represented 2 between your classes something like the 1 following:
Address.AddressType
AddressType.Addresses
As Keith hints, this article suggests TPT in EF 2 scales horribly, but I haven't tried it 1 myself.
More Related questions
We use cookies to improve the performance of the site. By staying on our site, you agree to the terms of use of cookies.