Использует ли наследование таблицы допустимый способ избежать использования таблицы соединений?

Question

Я выполнял методологию DDD в основном для этого проекта, поэтому, как и любой DDD'er, я сначала создал классы модели домена. Я намерен использовать эти POCO как мои объекты LINQ-to-SQL (да, они не чистые POCO, но я в порядке). Я начал создавать схему базы данных и внешний XML-файл сопоставления, но у меня возникают некоторые проблемы с моделированием связей и ассоциаций сущностей.

Артефакт представляет собой документ. Артефакты могут быть связаны либо с задачей, либо с случаем. Субъект Дела выглядит следующим образом:

public class Case 
{ 
    private EntitySet<Artifact> _Artifacts; 
    public IList<Artifact> Artifacts 
    { 
      get 
      { 
       return _Artifacts; 
      } 
      set 
      { 
       _Artifacts.Assign(value); 
      } 
    } 
    . 
    . 
    . 
} 

Поскольку артефакт может быть связан либо с футляром, или задачами, я имею возможность использовать наследование от класса артефакта для создания CaseArtifact и TaskArtifact производных классов. Единственное различие между двумя классами, однако, было бы наличием поля Case или поля Task. В базе данных, конечно, у меня будет одна таблица, Артефакт, с полем дискриминатора типа и полями CaseId и TaskId.

Вопрос: является ли это приемлемым подходом к решению этой проблемы или создаст таблицу объединений для каждой ассоциации (2 новых таблицы, всего), чтобы быть лучшим подходом?

Answer 1

Я бы, вероятно, столкнулся с двумя таблицами - это делает ссылочную целостность-PK/FK немного проще обрабатывать в базе данных, так как вам не придется иметь сложное ограничение, основанное на столбце селектора.

(чтобы ответить на ваш комментарий - я столкнулся с таким пространством, как сообщение). Моя общая философия заключается в том, что база данных должна быть смоделирована с использованием лучших практик базы данных (защитите свой периметр и обеспечьте согласованность базы данных, используя столько RI и возможные ограничения, обеспечивайте весь доступ через SP, активность журнала по мере необходимости, управляйте всеми режимами доступа, при необходимости используйте триггеры), а объектная модель должна быть смоделирована с помощью лучших методов ООП для обеспечения мощного и согласованного API. Это задача вашего SP/уровня доступа к данным для устранения несоответствия импеданса.

Если вы просто сохраняете хорошо спроектированную модель объекта в базе данных, ваша база данных не будет иметь значительной внутренней ценности (трудно выполнить анализ данных, склада, метаданных и т. Д.) При просмотре без прохождения объектива объектная модель - это нормально для некоторых приложений, как правило, не для моих.

Если вы просто подражаете хорошо спроектированной структуре базы данных в своем приложении, не предоставляя богатый API OO, ваше приложение будет сложно поддерживать, а внутренние структуры будут неудобны - как правило, очень процедурные, жесткие и с много дублирования кода.

Answer 2

Я хотел бы рассмотреть в поиске сходств между случае и задачи, из-за отсутствия лучшего слова давайте назовем это «CaseTask», а затем суб-типирование (наследовании) от того. После этого вы прикрепляете документ к супертипу.

ОБНОВЛЕНИЕ (после комментариев):
Тогда я бы подумал об этом. Каждый документ может быть прикреплен к нескольким случаям или задачам.