Home/ Questions/Q 192437
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T16:25:32+00:00

Okay, I’ll be straight with you guys: I’m not sure exactly how Domain Driven

  • 0

Okay, I’ll be straight with you guys: I’m not sure exactly how Domain Driven my Design is, but I did start by building Model objects and ignoring the persistence layer altogether. Now I’m having difficulty deciding the best way to build my tables in SQL Server to match the models.

I’m building a web application in ASP.NET MVC, although I don’t think the platform matters that much. I have the following object model hierarchy:

Property - has properties such as Address and Postcode

 which have one or more

Case - inherits from PropertyObject
Quote - inherits from PropertyObject

 which have one or more 

Message - simple class that has properties Reference, Text and SentDate

Case and Quote have a lot of similar properties, so I also have a PropertyObject abstract base class that they inherit from. So Property has an Items property of type List which can contain both Case and Quote objects.

So essentially, I can have a Property that has a few Quotes and Cases and a load of Messages that can belong to either of those.

A PropertyObject has a Reference property (and therefore so do Quote and Case) so any Message object can be related back to a Quote OR Case by it’s Reference property.

I’m thinking of using the Entity Framework to get my Models in and out of the database.

My initial thoughts were to have four tables: Property, Case, Quote and Message.

They’d all have their own sequential IDs, and the Case and Quote would be related back to Property by a PropertyID field.

The only way I can think of to relate a Message table back to the Case and Quote tables is to have both a RelationID and RelationType field, but there’s no obvious way to tell SQL server how that relationship works, so I won’t have any referential integrity.

Any ideas, suggestions, help?

Thanks,
Anthony

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I am assuming Property doesn’t also inherit from PropertyObject.

    Given that these tables, Property, Case, Quote and Message, leads to a Table per Concrete Class or TPC inheritance strategy, which I generally don’t recommend.

    My recommendation is that you use either:

    • Table per Hierarchy or TPH – Case and Quote are stored in the same table with one column used as a discriminator, with nullable columns for properties that are not shared.
    • Table per Type or TPT – add a PropertyObject table with the shared fields and Case and Quote tables with just the extra fields for those types

    Both of these strategies will allow you to maintain referential integrity and are supported by most ORMs.

    see this for more: Tip 12 – How to choose an inheritance strategy

    Hope this helps
    Alex

    • 0