Является ли использование наследования таблиц правильным способом избежать использования таблицы объединения?

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

Я бы рассмотрел нахождение общих черт между case и task , из-за отсутствия лучшего слова назовем его " CaseTask " и затем введем подтип наследование) от этого. После этого вы прикрепляете документ к супертипу.

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