Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > СУБД, общие вопросы > Как реализуется наследование в реляционных БД?..

Автор: Kurt 3.4.2005, 20:53

Есть ER-диаграмма. В ней применено наследование.
Теперь стоит задача реализовать все это в РЕЛЯЦИОННОЙ БД. Конкретно, в FireBird, но возможен вариант MySQL.
Расскажите, как переносится наследование на чисто реляционные базы? Каким образом это реализуется?

Автор: Domestic Cat 3.4.2005, 21:44

В самом простом случае наследования от одного класса- есть 3 варианта.
1. Создать таблицу для суперкласса с его аттрибутами, и каждому сабклассу по таблице с их аттрибутами. Связаны через примари ключ.
2. Создать одну таблицу для суперкласса со всеми аттрибутами, включая сабклассы
3. Создать таблицы только для сабклассов, каждая будет включать аттрибуты сабкласса + суперкласса.

Наиболее оптимальный первый вариант, афаик.

Автор: LSD 3.4.2005, 22:40

Я видел проекты с сериализацией объектов. Там структура таблиц, вообще не зависела от того какие объекты в ней хранятся.

Автор: Domestic Cat 3.4.2005, 22:43

Цитата(LSD @ 3.4.2005, 13:40)

Дык речь не об объектах, а о ER (Entity-Relationship) диаграммах smile

Автор: LSD 3.4.2005, 22:51

Дык таким макаром можно шо хош запихать в РСУБД, правда эффективность...

Автор: Domestic Cat 3.4.2005, 23:02

Цитата

Дык таким макаром можно шо хош запихать в РСУБД, правда эффективность...

Не понял

ER - это схемка такая на бумаге, ее нужно перевести в ряд sql команд для рсубд, если я пральна понимаю smile

Автор: Kurt 4.4.2005, 00:56

Цитата

ER - это схемка такая на бумаге, ее нужно перевести в ряд sql команд для рсубд, если я пральна понимаю

Ага. Абсолютно пральна. Задача именно такая..
Хм.. Сейчас вспоминаю, что кто-то мне говорил, будто 3 вариант:

Цитата

3. Создать таблицы только для сабклассов, каждая будет включать аттрибуты сабкласса + суперкласса.

наиболее часто используется.
А какой вариант наиболее оптимален по скорости?

Автор: Domestic Cat 4.4.2005, 01:02

Я не большой спец smile

Вроде бы третий вариант приведет не очень хорошим релейшншипам

Автор: Kurt 4.4.2005, 01:06

Почему?
Единственный трабл, к-й сразу бросается в глаза - если надо будет по ID узнать тип объекта - надо будет делать запросы во все таблицы сабклассов.
Ну и, возможно, избыточность. Но не обязательно.

Автор: LSD 4.4.2005, 18:40

Если я ничего не путаю то в Oracle, объекты хранятся следующим образом:

создается таблица для базового типа, со всеми полями объекта + тип объекта + OUID (Object Unique Identifier)
для каждого субкласса создается таблица с полями которые были добавленны + OUID (вероятнее всего foreign key на базовую таблицу)

Соответственно при записи объекта он разбивается на несколько таблиц, а при чтении наоборот собирается.

Автор: simanyay 5.4.2005, 12:18

Цитата(Kurt @ 4.4.2005, 03:06)

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

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

Автор: maxim1000 5.4.2005, 12:44

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