Results 1 to 4 of 4

Thread: Many-to-one Entity Design Question

  1. #1

    Thread Starter
    Addicted Member
    Join Date
    Jan 2008
    Location
    Tennessee
    Posts
    130

    Many-to-one Entity Design Question

    I have an issue where I have objects in the domain like Device, Termination, WireTag, WireType, etc. This is with relation to modeling of an engineering design application. These objects provide the information represented by a single database record, let's call this object DeviceWiringRecord. I've been working on an API that uses EntityRepositories, UnitsOfWork, etc. This process also translates the domain to a DTO/POCO object. This works great with a one-to-one relationship like DeviceWiringRecord to DeviceWiringRecordDTO with a data-level infrastructure to read/write/update the information. But as I'm building out the domain, the fact that Device, Termination, WireTag, WireType, etc all provide information represented by the DB record, I really have a many-to-one object relationship. What's the best way to handle this? BTW... though this is designed using basic DB principles, the database is actually CAD system drawing files. So I'm asking the question with regards to patterns and design principles. Specific technologies like EntityFramework will not work with this though. Thanks in advance for any assistance!

  2. #2
    PowerPoster
    Join Date
    Jul 2002
    Location
    Dublin, Ireland
    Posts
    2,148

    Re: Many-to-one Entity Design Question

    Are the objects basically super-types of a common record type? (i.e. do all objects share some common properties - maybe location?)

    If so you'd need one table for the common elements and linked tables for each sub-type with an optional link back to the common elements table.

  3. #3

    Thread Starter
    Addicted Member
    Join Date
    Jan 2008
    Location
    Tennessee
    Posts
    130

    Re: Many-to-one Entity Design Question

    Unfortunately no. I wish though. Each object actually represents a different part of the record. The record does have an ID (called a Handle) that uniquely identifies that. Could that be used to link object information somehow?

  4. #4
    PowerPoster
    Join Date
    Jul 2002
    Location
    Dublin, Ireland
    Posts
    2,148

    Re: Many-to-one Entity Design Question

    Then you might do better with a NoSQL type of database? Use the handle (and the object type) as the record aggregate and all the properties that pertain to the object hang off that?

    You'll need to turn the record into the appropriate DTO class based off the object type field. (Conceptually similar to event sourcing ish...)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width