Должны ли быть 2 таблицы данных для класса Parent и Child в Java?

Question

У меня есть два класса Parent и Child.

class Child extends Parent {
    private String extraField1;
    private String extraField2;
    ...
}

Child класс имеет 2 дополнительных поля extraField1 и extraField2.

Q1. Должен ли я сделать два diff. таблицы в базе данных: одна для Child и другая для Parent?

или

Q1. Следует ли добавить два столбца в таблицу Parent (каждый столбец для одного дополнительного поля) и сохранить Child в таблице Parent.

=============================== РЕДАКТИРОВАНИЕ =============== ========================

Да, Child и Parent - это классы в одной иерархии.

Answer 1

Должно ли быть 2 таблицы данных для класса Parent и Child в Java?

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

Скотт Эмблер подробно описывает различные подходы в разделе 2. Отображение структур наследования его знаменитой статьи Отображение объектов в реляционных базах данных: подробное отображение O / R , которое я цитирую ниже:

(...) В этом раздел вы увидите, что есть три основных решения для картирования наследование в реляционном база данных и четвертый дополнительный Техника, которая выходит за рамки наследования отображение. Эти методы:

• Сопоставить всю иерархию классов с одной таблицей
• Сопоставить каждый конкретный класс с отдельной таблицей
• Сопоставить каждый класс с отдельной таблицей
• Отображение классов в общую структуру таблицы

Для полного сравнения (с преимуществами, недостатками и рекомендациями о том, когда использовать), посмотрите раздел 2.6 Сравнение стратегий .

Я не могу сделать лучше, чем он, так что нет смысла перефразировать его, просто обратитесь к оригиналу.

Answer 2

Шаблоны прикладной архитектуры предприятия также охватывает это в своих главах по Наследование по одной таблице , Наследование по таблице классов и Конкретно наследование таблиц .

Покрытие похоже на то, что сказал Паскаль. Единого истинного пути не существует, но книга дает вам хорошее представление о затратах и ​​выгодах, например

Преимущества наследования бетонных таблиц:

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

Слабые стороны наследования бетонных таблиц:

• Первичные ключи могут быть трудными для обработки.
• Вы не можете навязать связи базы данных с абстрактными классами.
• Если поля в классах домена перемещаются вверх или вниз по иерархии, Вы должны изменить таблицу определения. Вам не нужно делать как много изменений, как с таблицей классов Наследование (285), но вы не можете игнорировать это как можно с Single Наследование таблиц (278).
• Если поле суперкласса изменяется, вам нужно изменить каждую таблицу, которая имеет это поле, потому что суперкласс поля дублируются по всей таблицы.
• Находка в суперклассе заставляет вас проверять все таблицы, что приводит для нескольких обращений к базе данных (или странное соединение).