Как Вы эффективно моделируете наследование в базе данных?

Каковы лучшие практики для моделирования наследования в базах данных?

Каковы компромиссы (например, queriability)?

(Я больше всего интересуюсь SQL Server и.NET, но я также хочу понять, как другие платформы решают эту проблему.)

123
задан Madhur Bhaiya 7 October 2019 в 07:30
поделиться

0 ответов

Существует несколько способов смоделировать наследование в базе данных. То, которое Вы выбираете, зависит от Ваших потребностей. Вот несколько опций:

Таблица на тип (TPT)

Каждый класс имеет свою собственную таблицу. Базовый класс имеет все элементы базового класса в нем, и каждый класс, который происходит из него, имеет свою собственную таблицу с первичным ключом, который является также внешним ключом к таблице базового класса; класс полученной таблицы содержит только различные элементы.

Так, например:

class Person {
    public int ID;
    public string FirstName;
    public string LastName;
}

class Employee : Person {
    public DateTime StartDate;
}

привел бы к таблицам как:

table Person
------------
int id (PK)
string firstname
string lastname

table Employee
--------------
int id (PK, FK)
datetime startdate

Таблица на иерархию (TPH)

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

, Учитывая классы выше, Вы заканчиваете с этой таблицей:

table Person
------------
int id (PK)
int rowtype (0 = "Person", 1 = "Employee")
string firstname
string lastname
datetime startdate

Для любых строк, которые являются rowtype 0 (Человек), startdate всегда будет пустым.

Таблица на бетон (TPC)

Каждый класс имеет свою собственную полностью сформированную таблицу без ссылок прочь на любые другие таблицы.

, Учитывая классы выше, Вы заканчиваете с этими таблицами:

table Person
------------
int id (PK)
string firstname
string lastname

table Employee
--------------
int id (PK)
string firstname
string lastname
datetime startdate
144
ответ дан Brad Wilson 24 November 2019 в 01:12
поделиться

Надлежащее проектирование баз данных - ничто как надлежащий объектный дизайн.

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

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

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

Лучше спрашивать себя, что делают факты Вы хотите сохранить, на что вопросы - Вы собирающийся хотеть ответы, что делают отчеты Вы хотите генерировать.

, Как только надлежащий дизайн DB создается, тогда это - простой вопрос для создания запросов/представлений, которые позволяют Вам сериализировать свои объекты к тем отношениям.

Пример:

В системе бронирования гостиницы, Вы, возможно, должны сохранить то, что у Jane Doe есть резервирование для комнаты в Seaview Inn на 10-12 апреля. Это - атрибут потребительского объекта? Действительно ли это - атрибут объекта отеля? Действительно ли это - объект резервирования со свойствами, которые включают клиента и отель? Это могли быть любые из тех вещей в объектно-ориентированной системе. В базе данных это не ни одна из тех вещей. Это - просто пустой факт.

Для наблюдения различия рассмотрите следующие два запроса. (1) Сколько бронирования номеров в отеле Jane Doe имеет в течение следующего года? (2) Сколько комнат заказано на 10 апреля в Seaview Inn?

В объектно-ориентированной системе, запросите (1), атрибут потребительского объекта, и запрос (2) является атрибутом объекта отеля. Те - объекты, которые представили бы те свойства в их API. (Хотя, очевидно, внутренние механизмы, которыми получены те значения, могут включить ссылки на другие объекты.)

В системе реляционных баз данных, оба запроса исследовали бы отношение резервирования для получения их чисел, и концептуально нет никакой потребности обеспокоиться любым другим "объектом".

Таким образом, это путем попытки сохранить факты о world— вместо того, чтобы пытаться снабдить объекты attributes—, что создается надлежащая реляционная база данных. И как только это правильно разработано, тогда полезные запросы, которые не мечтались о во время стадии проектирования, могут быть легко созданы, так как все факты должны были выполнить те запросы, находятся в их надлежащих местах.

122
ответ дан Hayee 24 November 2019 в 01:12
поделиться

Короткий ответ: Вы не делаете.

, Если необходимо сериализировать объекты, используйте ORM, или еще лучше что-то как activerecord или prevaylence.

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

8
ответ дан Marcin 24 November 2019 в 01:12
поделиться

Существует два основных типа наследования, которое можно установить в DB, таблице на объект и таблице на Иерархию.

Таблица на объект - то, где у Вас есть основная таблица объекта, которая совместно использовала свойства всех дочерних классов. У Вас тогда есть на дочерний класс другая таблица каждый только со свойствами, применимыми к тому классу. Они связаны 1:1 их PK

alt text

, Таблица на иерархию - то, где все классы сидели за одним столом, и дополнительные свойства nullable. Их также поле различителя, которое является числом, которое обозначает тип, который запись в настоящее время содержит

alt text , SessionTypeID является различителем

, Цель на иерархию быстрее для запросов для того, поскольку Вам не нужны соединения (только значение различителя), тогда как цель на объект, необходимо сделать сложные соединения для обнаружения то, что вводит что-то, а также retreiuve все его данные..

Редактирование: изображения, которые я показываю здесь, являются снимками экрана проекта, я продолжаю работать. Изображение Актива не завершено, следовательно пустой из него, но это должно было главным образом показать, как его установка, не, что вставить Ваши таблицы. Это ваше дело;). Таблица сессии содержит информацию сессии Виртуального сотрудничества и может иметь несколько типов сессий в зависимости от того, какое сотрудничество включено.

4
ответ дан Glorfindel 24 November 2019 в 01:12
поделиться

Вы нормализовали бы своей базы данных, и это на самом деле зеркально отразит Ваше наследование. Это могло бы иметь производительность degradance, но это - то, как это с нормализацией. Вероятно, необходимо будет использовать хороший здравый смысл найти баланс.

1
ответ дан Per Hornshøj-Schierbeck 24 November 2019 в 01:12
поделиться

повторение подобного ответа потока

в отображении O-R, наследование отображается на родительскую таблицу, где родительские и дочерние таблицы используют тот же идентификатор

, например

create table Object (
    Id int NOT NULL --primary key, auto-increment
    Name varchar(32)
)
create table SubObject (
    Id int NOT NULL  --primary key and also foreign key to Object
    Description varchar(32)
)

, SubObject имеет отношения внешнего ключа к Объекту. при создании строки SubObject необходимо сначала создать Объектную строку и использовать идентификатор в обеих строках

РЕДАКТИРОВАНИЕ: если бы Вы обращаетесь к поведению модели также, Вам была бы нужна таблица Type, которая перечислила отношения наследования между таблицами и определила имя сборки и имя класса, которое реализовало поведение каждой таблицы

, походит на излишество, но что все зависит от того, для чего Вы хотите использовать его!

1
ответ дан Community 24 November 2019 в 01:12
поделиться

Используя Алхимию SQL (Python ORM), можно сделать два типа наследования.

тот у меня был опыт, использует таблицу ожога и имеет дискриминантный столбец. Для экземпляров, база данных Sheep (никакая шутка!) сохранил всех Овец в одной таблице, и Бараны и Овцы были обработаны с помощью гендерного столбца в той таблице.

Таким образом, можно запросить для всех Овец и получить всех Овец. Или можно запросить Ram только, и это только получит Поршни. Можно также сделать, вещам нравится, имеют отношение, которое может только быть Поршнем (т.е., Родитель Овцы), и так далее.

1
ответ дан Matthew Schinckel 24 November 2019 в 01:12
поделиться

Обратите внимание, что некоторые механизмы базы данных уже обеспечивают механизмы наследования исходно как Пост-ГРЭС . Посмотрите документация .

Для примера, Вы запросили бы систему Человека/Сотрудника, описанную в ответе выше подобного это:

  /* This shows the first name of all persons or employees */
  SELECT firstname FROM Person ; 

  /* This shows the start date of all employees only */
  SELECT startdate FROM Employee ;

В этом выбор Вашей базы данных, Вы не должны быть особенно умными!

1
ответ дан Pierre 24 November 2019 в 01:12
поделиться
Другие вопросы по тегам:

Похожие вопросы: