How to model concrete table relationship where a child entity can contain different data, where the data belongs to the same generic type?

Question

I am thinking of using Concrete Table Inheritance for a use case, and need help determining if I need to use identifying vs non-identifying relationship, and also if how to structure my tables exactly.

My use case

I have an HTML form object where the form is the same mostly for many things, i.e. it is a large form that is identical for different products, except for product_options, which are different depending on exact product_type. I want to save form data into tables, for storage/retrieval. I think I want to use Concrete Table implementation, and need feedback on if that's the way to do it.

Here is what I am thinking:

Say if I want to retrieve information for product of type "A", I

1. Read selection_for, retrieve product_type
2. Based on product_type I read the appropriate options table

This seems to be a bit complicated...

I am also using Doctrine ORM to drive the database behind the scenes, so such data manipulation may prove to be difficult to implement via ORM API, but I wanted to consider this option first.

Questions:

• Will my design work as-is? Can it be improved upon? Did I implement Concrete Table design correctly?
• Do I use identifying or non-identifying relationship for the product option tables?

I can also do an alternative diagram like so:

and if one of those foreign keys is not NULL, then I read that key and then read the appropriate table to retrieve the data.

Questions:

Are any pros or cons to this second methods compared to the first one?

Answer 1

Turns out Doctrine ORM has this handled. 3 different ways:

Mapped Superclass

Creates 3 tables in my case, each has both shared and concrete fields/columns

Single Table Inheritance

Puts all options into a single table (one table, no other tables are used). Uses a discriminator field to pull the correct options.

Class Table Inheritance

aka JOINED type. Creates 4 tables in my case, one for each type, plus main. Options tables contain only the options relevant to them, and main table contains any shared fields, and the discriminator field.

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html

I guess just what I was looking for. This takes SQL work out of my hands.

Now, to make the decision on which one to use ....