Моделирование отношений между унаследованными типами в ORM

Question

Я ищу совет или альтернативу для моделирования следующих отношений.

Рассмотрим:

и применение указанных отношений:

г. У военачальника есть много вариантов, однако, если ресурс исчезает, его выбор удаляется каскадом. Теперь огнестрельное оружие и пули - оба ресурса. Огнестрельное оружие может использовать много видов пуль (FMJ, HP, P +, взрывчатка? ..). Пули также могут быть использованы в различных видах огнестрельного оружия (АК, М60, М14). Поэтому я также хотел бы убедиться, что если Пуля больше не будет доступна, вышеупомянутые отношения с огнестрельным оружием больше не будут существовать, и наоборот.

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

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

Вы заметите, что Тип ресурса 2 не содержит Set<Type1>, а просто ссылку на (Long)ResourceId некоторого Огнестрельного оружия. (Пули не могут держать огнестрельное оружие, даже если верно обратное, и ради аргумента, да, это волшебное оружие может стрелять многими типами пуль).

Почему у меня есть коллекции идентификаторов, а не объектов? Что ж, если я добавлю тип маркера, представляется более эффективным добавить ссылку на Id в таблицу ассоциации, чем извлечь огнестрельное оружие и «добавить» к нему объект маркера. Таким образом, когда я получаю объект огнестрельного оружия, я также не получаю все пули, которые он может использовать. (Меньше накладных расходов памяти для всех этих объектов, вместо этого просто набор идентификаторов).

Так в чем же был вопрос?:

1.) Это не похоже на необычную модель. Есть ли лучший способ его моделировать?

2.) Я еретик ООП, чтобы использовать ссылки вместо объектов? Должен ли я просто использовать объекты?

Моя главная проблема

3.) Если 1 и 2 не так, как я могу смоделировать это в JDO? Я экспериментировал пару дней, и проблема, с которой я продолжаю сталкиваться, заключается в том, что JDO не может распознать связь между наборами длинных. Каждый найденный мной пример показывает использование объектов Composition, а не ссылок на атрибуты M-N. Если я не укажу другой персистентный объект, то может возникнуть путаница. Атрибут сохраняемого объекта не работает.

UPDATE:

Сегодня я получил ответ от форума DataNucleus, Вот ветка Проблема была связана с моим вопросом № 2 выше. Моя попытка сэкономить часть памяти была источником моих трудностей. Я не могу установить связь между коллекциями, чьи типы элементов не являются другими постоянными классами без фальсификации присяжных. Мне нужно немного изменить дизайн.

РЕШЕНИЕ:

Смотрите мой ответ ниже

Я ценю вклад каждого.

Answer 1

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

Я хотел, чтобы коллекции длинных позиций на каждой стороне отношения сохранялись вместе в таблице соединений . Я также хотел убедиться, что эти long (представляющие PK стороны far отношения) будут настроены как составные PK, каждая половина которого будет указывать назад на таблицу, которую они представляют. Несмотря на то, что это выглядело довольно тривиально, я неоднократно сталкивался с проблемами при создании третьего столбца в таблице соединений создателем схемы JDO. Вместо того чтобы сопоставлять (длинные) идентификаторы с соответствующим объектом, он рассматривал их как «элемент» и помещал их в этот третий столбец. Это, конечно, сломало первичный ключ и привело к тому, что при сохранении какого-либо из объектов возникли исключения.

Ни в одной документации не было предложено никакого решения для этого, поэтому я предлагаю его ниже:

1. Я перестал использовать аннотации или отдельный ORM-файл и застрял только с файлом метаданных package.jdo. (в этом нет необходимости, но это хорошая практика (отредактируйте XMl и Class), и это упростило задачу.)

2. Я дал * определенные имена столбцам объединяемых таблиц, чтобы они не генерировали свои собственные автоматически.

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

Таким образом, метаданные .jdo выглядят следующим образом:

    <class name="Firearm" table="APP_JDO_FIREARMS">
        <inheritance strategy="new-table"/>
        <field name="name"/>

         ...
        <field name="bullets" mapped-by="firearms" table="APP_JDO_BULLET_FIREARM">
            <collection element-type="java.lang.Long"/>
            <join>
                <column name="FIREARM_ID"/>
            </join>
            <element>
                <column name="BULLET_ID"/>
            </element>
        </field>
    </class>

    <class name="Bullet" table="APP_JDO_BULLETS">
        <inheritance strategy="new-table"/>
        <field name="name"/>

        ...
        <field name="firearms" persistence-modifier="persistent" mapped-by="bullets" table="APP_JDO_BULLET_FIREARM">
            <collection element-type="java.lang.Long"/>
            <join>
                <column name="BULLET_ID"/>
            </join>
            <element>
                <column name="FIREARM_ID"/>
            </element>
        </field>
    </class>

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

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

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

Answer 2

Я не знаю JDO, поэтому я собираюсь ответить на ваш вопрос с точки зрения JPA и в целом.

Когда дело доходит до отображения наследования с помощью ORM, вам необходимо задать себе следующие вопросы.

1) Вы ищете поддержку ploymorphic запросов.т.е. вы хотите сделать запрос для объектов типа ресурсов и получить список объектов типа пуль и огнестрельного оружия.

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

Если вам нужны полиморфные запросы, у вас может быть три возможных структуры таблиц для отображения наследования, которые называются стратегиями в JPA.

1. Таблица для конкретного класса
2. Singleтаблица со столбцом дискриминатора
3. Одна таблица на класс в иерархии наследования (что у вас есть в вопросе)

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

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

http://www.apress.com/9781430219569 имеет достойное обсуждение вопросов с отображением наследования.