Реляционная БД и иерархии классов

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

0

Самые очевидные способы решения (отсюда):
1. Одна таблица с общими для всех полями и дополнительно для каждого типа своя таблица с особенными
2. Одна общая таблица со всеми-всеми полями
3. Отдельные таблицы для каждого типа

По вашему критерию - простота добавления новых наследников лучше подходят вариант 1 и 3.

0

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

0

Спасибо за ответы, но они привели к появлению новых вопросов
Получается, что в таблицу с полями базового класса необходимо добавить некий атрибут "тип", чтобы при загрузке создать экземпляр нужного производного класса? Перебирая строки запроса к этой таблице по одной, нам придется делать по одному запросу к производным таблицам для каждого элемента. Это будет полный п... то есть я хотел сказать, восторг, сэр (С) "Убрать перископ".
Будет ли более оптимально для всех известных типов сделать по запросу select * from base inner join derived on base.id == derived.base_id, а потом уже создавать объекты конкретного типа из результатов этих укрупненных запросов?

0

Да, лучше добавить "тип". Теоретически можно обойтись и без него, но потом возможно понадобятся задачи где он пригодится.
По второму вопросу: все зависит от кол-ва наследников и от кол-ва полей в каждом.
Возможно, быстрее окажется примерно такой запрос:

0

Я не очень пока силен в SQL. Правильно ли я понимаю, что Ваш запрос вернет строки для всех объектов, где для отсутствующих полей просто будет значение NULL? Это, конечно, самый правильный подход. Спасибо за совет

0

Да, вы правильно понимаете.
Насчет правильности подхода: если будет очень много разных полей у потомков - запрос сильно разрастется и может начать тормозить.

0

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

ключевые слова table per hierarchy и table per class (или table per type) .
В первом случае всё хранится в одной таблице с дополнительным полем "тип". Во втором - в разных, связываемых в тип JOIN'ами. Можешь поискать как это делают разные ORM (тот же Entity Framework), либо вообще сразу их использовать.

0

soft.creator, трудно советовать абстрактно. Есть разные подходы и они зависят от требований к производительности, исходных данных. Предполагаемой динамики развития предметной области.

Если не секрет, в чем смысл задачи? Зная смысл можно точнее определить, какой способ подойдет в данном варианте.
Лично я для своих задач - за вариант с одной таблицей.
===============
Говорить о каком-то наследование в рамках реляционных СУБД бессмысленно. Его там нет. Можно, конечно, отобразить базу в реляционной модели, но это не то.
Поэтому не "есть базовый класс и несколько его наследников", а "есть несколько сущностей, незначительно отличающихся набором атрибутов".

0

Идея в следующем - пишу некий менеджер задач (GTD-style) для Android. Решил использовать для хранения данных sqlite. Задачи могут быть разных типов, в идеале просто реализуя один и тот же интерфейс. Естественно, считывать список этих задач хочется одним запросом. А поскольку с базами данных я знаком только по односеместровому университетскому курсу - решил спросить совета у людей знающих.

0

soft.creator, а пользователю будет разрешено создавать свои типы задач?

0

Нет, но на будущее решил оставить лазейку в виде этого упомянутого интерфейса. И себе проще будет, и появится возможность потом какой-нибудь конструктор задач прикрутить. Хотя в целесообразности второго сильно сомневаюсь.

0

soft.creator,
Итак, получается.

База однопользовательская.

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

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

И пусть таблица будет частично разряжена. В современных базах нет нужды экономить на пустых значениях. Такие значения в базе занимают несколько байт.


Важная рекомендация.
Еще раз, как следует, провести анализ предметной области. Возможно "отличающиеся" поля на самом деле совсем не отличаются, а просто по разному называются в обычной жизни.

===============
Если бы я решал эту задачу и было бы обязательным требование "Пользователь может создавать свои типы задач", то я бы в данной задаче, учитывая ее другие требования, вообще бы не заморачивался бы на РСУБД, а сделал бы базу на XML.

А вот если бы надо было масштабирование, многопользовательский доступ - то я не знаю что бы применил. Решал бы по конкретным требованиям.

0

Спасибо за анализ и совет, но на XML, мне кажется, будет чуть посложнее. Основной задачей было как можно проще (в плане количества кода) хранить данные и иметь семантику транзакций при выполнении операций. С XML все же придется писать какой-то свой загрузчик, тем более, что задачи зависимы друг от друга и надо будет еще и разбираться в правильном сохранении ссылок. У меня есть такой код на С++, но на Java я его так просто не портирую.

0

soft.creator,
Всегда приходится выбирать между чем-то и чем-то
============
В C# есть множество инструментов для самой изошренной работой с XTML
Только не подумайте, что я за него агитирую. Просто для некоторых задач его использование оправдано

0