Hibernate: таблица для конкретного класса против таблицы для подкласса - PullRequest
1 голос
/ 30 октября 2011

Я планирую / проектирую свою базу данных для моего текущего проекта (Java). Для этого проекта я собираюсь использовать Hibernate.

В моем проекте у меня есть базовый класс / интерфейс под названием Command. Фактически класс Command содержит только идентификатор поля (уникальный).

public interface Command {
   public int getId();
   public void execute();
}

Итак, у каждого общего подкласса Command есть уникальный идентификатор и метод execute, который реализуется подклассами.

Существует много подклассов, таких как MoveCommand, ResizeCommand и т. Д., Которые не имеют общих полей данных (кроме идентификатора).

Например:

public class MoveCommand implements Command {
   private int id;
   private int oldX;
   private int oldY;
   private int newX;
   private int newY;
   public void execute() { ... }
   public int getId(){return id; }
}

public class ResizeCommand implements Command {
   private int id;
   private int oldWidth;
   private int oldHeight;
   private int newWidth;
   private int newHeight;
   public int getId(){return id; }
   public void execute() { ... }
}

Затем у меня есть другой класс, который называется Document, который содержит список команд

public class Document {
  private List<Command> commands;
}

Таким образом, многие запросы базового класса «выберите из команды» были выполнены во время выполнения.

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

В SQL: лучше ли в этом случае JOIN (таблица на подкласс) или UNION (таблица на конкретный класс)?

Кто-нибудь имеет опыт работы с этой темой?

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

1 Ответ

1 голос
/ 30 октября 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...