Is inheritance required when injecting entities?

[NotionCommotion]

I wish to create and store in a DB three objects which are created using injection;

$myAObject=new BaseEntity(new InjectedThingA());
$myBObject=new BaseEntity(new InjectedThingB());
$myCObject=new BaseEntity(new InjectedThingC());

BaseEntity is defined by SQL table base_entity and my three injected objects InjectedThingA,  InjectedThingB, and InjectedThingC are each defined by SQL tables injected_thing_a, injected_thing_b, injected_thing_c, respectively.  Each of these injected tables has autoincrement column id plus whatever other columns, and base_entity includes a column injected_thing_id.  But this won't work since this ID is not unique across InjectedThings and also poor since there is no foreign key, so instead I do the following.

InjectedThingA extends AbstractInjectedThing
InjectedThingB extends AbstractInjectedThing
InjectedThingC extends AbstractInjectedThing

Then I add an autoincrement id column to AbstractedInjectedThing and place a one-to-one constraint from column id in InjectedThingA,  InjectedThingB, and InjectedThingC to column id in AbstractedInjectedThing.

So, I still need to use inheritance, right?  I don't think that this type of inheritance brings the baggage which MyInheritedEntity extends BaseEntity does and I am okay with it, but just want to make sure I am doing this right.

Thanks

Edited October 4, 2019 by NotionCommotion

[requinix]

Unless you need additional columns in AbstractInjectedThing, I don't see a point in using it in the database. (In code yes, at least an interface, just not in the database.)

If the only commonalities between those three things are the fact that they have IDs then they don't have anything in common. Inheritance wouldn't make sense.

My approach is to store a database table name with the ID. As in `injected_thing_table` with values "injected_thing_a/b/c". Make the three InjectedThings extend/implement something that enforces a way to retrieve a table name and key - perhaps a generic entity class that all your database models use - and BaseEntity can get the table name and ID from them to store. To reconstruct the object... it depends on the rest of your application; I've used a database table<->class mapping (which also backs the "retrieve a table name" functionality).

Why not store the class name instead of the table name? The database shouldn't have to know anything about code, and code symbols might change over time. They should not be coupled.

[NotionCommotion]

I think I am somewhat doing as you do.  I happen to be using Doctrine, but the approach is applicable without using it.  At a minimum, abstract_thing_table will have PK column ID and string column discriminator.  There is a schema config file that then maps this discriminator value to a specific class.

For one or two rare cases, I have a table just with these two columns.  While I think it is a little odd, a good part is if accessing the DB directly without Doctrine, I can save a JOIN.  For most, however, I moved any common columns in the three InjectedThing tables to abstract_thing_table.

[requinix]

Yeah, the process gets a little fuzzier when you use an ORM. From a purist standpoint I may or may not have that "table just with these two columns", but if it makes a difference with Doctrine then it's not like you're actively hurting yourself or anything in doing so.