Should there be 2 datatables for a Parent and Child class in Java?

I have two classes Parent and Child.

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

Child class has 2 extra fields extraField1 and extraField2.开发者_JAVA技巧

Q1. Should I make two diff. tables in the databse: one for Child and other for Parent?

or

Q1. Should I add two columns in the Parent table (each column for one extra field) and store the Child in the Parent table.

=============================== EDITED =======================================

Yes, Child and Parent are classes in the same hierarchy.

Should there be 2 datatables for a Parent and Child class in Java?

There is no universal answer to this question. There are actually several techniques to map an inheritance hierarchy into a relational database and they all have advantages and disadvantages. Choosing one or the other depends on your context.

Scott Ambler details the various approaches in the section 2. Mapping Inheritance Structures of his famous paper Mapping Objects to Relational Databases: O/R Mapping In Detail that I'm quoting below:

(...) In this section you’ll see that there are three primary solutions for mapping inheritance into a relational database, and a fourth supplementary technique that goes beyond inheritance mapping. These techniques are:

• Map the entire class hierarchy to a single table
• Map each concrete class to its own table
• Map each class to its own table
• Map the classes into a generic table structure

For a full comparison (with advantages, disadvantages and a recommendation on when to use), have a look at the section 2.6 Comparing The Strategies.

I can't do a better job than him so there is no point at paraphrasing him, just refer to the original paper.

Patterns of Enterprice Application Architecture covers this as well in its chapters on Single-table inheritance, Class-table inheritance, and Concrete-table inheritance.

The coverage is similar to what Pascal has said. There's no One True Way, but the book does give you a good breakdown of costs and benefits, e.g.

The strengths of Concrete Table Inheritance are:

• Each table is self-contained and has no irrelevant fields. As a result it makes good sense when used by other applications that aren't using the objects.
• There are no joins to do when reading the data from the concrete mappers.
• Each table is accessed only when that class is accessed, which can spread the access load.

The weaknesses of Concrete Table Inheritance are:

• Primary keys can be difficult to handle.
• You can't enforce database relationships to abstract classes.
• If the fields on the domain classes are pushed up or down the hierarchy, you have to alter the table definitions. You don't have to do as much alteration as with Class Table Inheritance (285), but you can't ignore this as you can with Single Table Inheritance (278).
• If a superclass field changes, you need to change each table that has this field because the superclass fields are duplicated across the tables.
• A find on the superclass forces you to check all the tables, which leads to multiple database accesses (or a weird join).