Каковы плюсы и минусы одной основной базовой таблицы, от которой наследуются все сущности?

Question

Сначала я использую Entity Framework Database для создания модели моего домена.

Я рассматриваю возможность создания базовой таблицы EntityBase с базовыми свойствами в:

 PK
 CreatedDate
 CreatedBy
 ModifiedDate
 ModifiedBy

 etc.

Использование наследования таблиц по типам В итоге я получу одну таблицу в базе данных, связанную со всеми другими таблицами сущностей:

EntityBase {
 EntityBase_PK => Identity PK
 CreatedDate
 CreatedBy
 ModifiedDate
 ModifiedBy
}

DerivedEntity1 {
 DerivedEntity1_PK => FK relationship to EntityBase on EntityBase_PK
 Property1 
 ...etc
}

DerivedEntity2 {
 DerivedEntity2_PK => FK relationship to EntityBase on EntityBase_PK
 Property2 
 ...etc
}

...etc

Я считаю, что это будет хорошо работать с Entity Framework, но я обеспокоен, если это хороший дизайн с точки зрения базы данных.

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

Мысли

Answer 1

Самой большой проблемой будет производительность. То, что вы описали, называется TPT-наследованием, и до тех пор, пока не выйдет .NET 4.5 с следующей версией EF , это будет сценарий с очень неэффективными запросами .

В случае ObjectContext API у него есть еще один минус. Вы не можете иметь ObjectSet производного типа, поэтому у вас будет один объект, установленный для всех объектов.

Если вам нужны хорошие концепции ООП, определите интерфейс со своими полями и реализуйте его во всех ваших сущностях, но не связывайте свои сущности с наследованием, которое охватывает как концептуальную модель, так и модель хранения. Даже TPC не очень хорошее решение, потому что он все еще требует уникальных первичных ключей среди всех таблиц => это приводит к руководству.

Answer 2

ОО-концепции редко переводятся в реляционные базы данных.Как администратор базы данных, я потратил больше времени на очистку попыток включить понятия ОО в реляционную базу данных, чем что-либо еще (и не потому, что я пурист, а потому, что они не работали.)

Если выхотите, чтобы во всех сущностях были уникальные PK, посмотрите на направляющие (или последовательные направляющие)

Ничего не помешает тому, что эти столбцы (CreatedDate, ModifiedDate и т. д.) будут в каждой таблице сущностей (на самом деле, это правильный дизайн)Однако вы будете видеть ужасные планы запросов, когда будете снова и снова присоединяться к своей базовой таблице.

Короче, я бы советовал против этого.

Answer 3

Очевидное преимущество, которое я вижу, заключается в том, что я получаю уникальный PK для всех сущностей во всей базе данных.

Не могли бы вы добиться этого, используя алгоритм HiLo или аналогичный для вастождества?