entity framework - What's the proper way to model this relationship in ERD and EF? -
i'm designing brand new db model new system. goal have stored in sql , mapped objects entity framework. i'm heavily using table-per-hierarchy pattern in order support complex object hierarchy , have inforced "properly" db engine.
i have following situation not sure how handle:
i have set of entities called resources. each resource specific type , contains number of specific attributes.
- resource (abstract class, maps resources table)
- resource table has discriminator column , resourceid primary key
- classes such as: serverresource (concrete class, inherits resource, maps urlresources table that's 1-1 resource... overall there dozehn other resources-types (number growing)
- each type of resource has set of unique properties specific resource)
i have number of entities called checks. each resource contains number of checks. resourceid foreign key in checks table. checks more interesting. there check types common or types of resources. , there check types specific types of resources. more precise:
- check (abstract class, maps checks table, checkid primary key)
- outagecheck (is supported types of resources)
- sslcertexpirationcheck (is supported 1 type of resource)
- etc. there approximately 3-4 types of checks per resource type. 1-2 of shared across resources, while rest custom specific resource
so, question how map checks both in erd entity framework. straight-forward approach create few dozen tables, each specific combo of resource type , check type. ie: serveroutagecheck, storageoutagecheck, urloutagecheck, urlsslexpiraitoncheck, serverlowmemorycheck, etc.
this seems little hard manage , maintain. love able share common checks within single table, specific common check (ie: outagecheck) , deviate on checks resource specific (ie: sslexpirationcheck). possible? or o^2 best can table-management perspective?
last thoughts. database frequenty read , infrequently written to. able cache heck out of reads, if necessary.
i'm going refer 3 tags, , advise pay particular attention info tab in each.
single-table-inheritance class-table-inheritance shared-primary-key
single table inheritance have tagged table-per-hierarchy. info tab discusses joys , woes associated having lots of nulls in single simple table.
class table inheritance alternative, 1 puts attributes pertain subclasses in tables attribute has meaning.
shared primary key design technique lets enforce one-to-one nature of subclass/superclass relationship, , gives handy way of joining specialized data generalized data.
most of have merely repeat what's in info tabs in 3 tags. may find associated questions , answers relevant case well.
Comments
Post a Comment