pydanny
commented
9 years ago Hi @jplehmann,
You raise some interesting points. However, in order to maintain consensus to make our book easier to use, we follow the Django specifications for terminology and definitions. If you think the definition is in error or needs to be clarified, the place to raise the issue is with Django itself.
I hope that explains our stance on the subject. :smile:
On page 63 and elsewhere the book equates multi-table inheritance with concrete inheritance. I think this is a misnomer (I may have seen this in Django docs too but I think it's misleading, IMO).
An equivalent name would be "joined table inheritance" which is what SQLAlchemy calls it. Joined table inheritance, where the class hierarchy is broken up among dependent tables, each class represented by its own table that only includes those attributes local to that class.
Two references:
An early reference -- Concrete inheritance is where there are no joins, and a class is represented only by a "leaf" table. http://martinfowler.com/eaaCatalog/concreteTableInheritance.html
A modern reference -- SQLAlchemy supports three forms of inheritance: single table inheritance, where several types of classes are represented by a single table, concrete table inheritance, where each type of class is represented by independent tables, and joined table inheritance, where the class hierarchy is broken up among dependent tables, each class represented by its own table that only includes those attributes local to that class. (top of page) http://docs.sqlalchemy.org/en/improve_toc/orm/inheritance.html#joined-table-inheritance http://docs.sqlalchemy.org/en/improve_toc/orm/inheritance.html#concrete-table-inheritance