PHP – Doctrine 2 and Concrete Table Inheritance

It's impossible to say whether a particular database design is bad without knowing what the application is doing, the shape of the data, the performance expectations and so on. While generally normalisation (to some degree) is seen as best practice, it's pretty common to denormalise areas of databases for performance reasons so good and bad are very much open for discussion without a lot more data than most people have when they start out.

Add in the many approaches that can be taken to object to relational mappings and things become even more complex as the "best" database structure will depend on the specific object model, the level of inheritance and so on.

By taking a one size fits all approach ORM persistence libraries will almost always produce a non-optimal database structure for any given situation and will use some things which can be seen as bad practice for that a given situation.

You certainly could write an ORM that normalised but you'd see fairly hefty performance implications as for every insert into a main table it needed to scan the various look up tables to see if values existed, if they did obtain their keys and if they didn't carry out the relevant inserts.

(When you do this by hand you can short cut some of this as you know you presented them with a drop down containing only valid value so you don't need to do these look ups, you can just use the key happy that it's going to be valid, the ORM couldn't make that assumption as it doesn't control the UI.)

But what you have to remember is that they aren't aiming to optimise for database performance or data integrity, they're optimising for development speed. If the specific structure of your data is important to you then you either need to code your object / RDBMS mappings by hand, or at the very least do a detailed assessment of all the libraries available and select the one which most closely meets your needs (if one exists).

Essentially it comes down to requirements and the trade off between well structured data, database performance and development speed. As with many trade-offs you don't get to pick all three.

It looks like you are having a design issue here: Tables should not extend the Database Abstraction Layer. Instead the DAL should be injected into the table as a dependency.

abstract class Table {
    protected $dal;

    public function __construct(DAL $dal) {
        $this->dal = $dal;
    }

    // whatever else all tables have in common
}

class Table_User extends Table {
    public function someMethod() {
        $this->dal->someOtherMethod();
    }
}

$table = new MyTable($dal);
$table->someMethod();

That way you will create a DAL at some upper scope and pass it down. This will also allow you to use multiple different database engines at the same time.

Additionally you obviously should not create your tables directly in your controller but let a specialized class do that. For example you could use a factory:

class TableFactory {
    protected $dal;

    public function __construct(DAL $dal) {
        $this->dal = $dal;
    }

    public function createTable($name) {
        $className = 'Table_' . $name;
        return new $className($this->dal);
    }
}

That way you can create a table factory at some point with an injected DAL and pass that table factory around.

$table = $factory->createTable('User');