SQL Database Design » 2. Terminology » 2.2 The Parent-Child Fuss

2.2 The Parent-Child Fuss

In texts about databases, you frequently come across the terms "parent" and "child tables". Child tables contain all referencing entities, whereas the parent table contains the referenced entities. This use of the parent-child terminology is very common, but it's plain wrong. Many developers have adopted this bad habit, as seen in books, online documentation, technical articles, and forum posts.

The parent-child terminology used to confuse me, because parent-child relationships aren't automatically given just because of a foreign key was specified. Parents and children are general terms to describe hierarchical, recursive (composite or part-of), tree-like data structures between entities and/or objects of the same or a super type. It's completely wrong to denote the referencing table as the child table just because it houses the foreign key to the referenced ("parent") table.

Take this example: a many-to-many relationship is always modeled using a separate "join" table, with the join table's foreign keys referencing the "real" interconnected tables. Does that mean, the interconnected tables are both parents of the join table just because they're referenced by it? It's stupid.

As a second example, take any two tables that relate to each other in a one-to-one fashion, like a car and an engine: technically, you can have the engine reference the car or vice versa. Both work. But, does that mean, when switching the foreign key to the other table, all of a sudden, the parent becomes the child and the child becomes the parent? Again, it's stupid.

Things become even more confusing when modeling hierarchical one-to-one relationships (inheritance). When defining sub tables, the relationship between the sub and super/base table is not "parent-child", but "super-sub" (or "sub-super"). The sub table simply isn't the child of the super table. Again, it's plain wrong to assume a parent-child relationship just because a foreign key was specified. Parent-child relationships are semantic and not just a matter of "who references who".

The parent-child terminology just doesn't work out in general. They are just part of one specific design constellation (trees), but no more. To avoid confusion, you have to be careful when and how to use parents and children. Keep in mind, that you will regularly stumble across these terms in inappropriate contexts (especially when visiting discussion forums). Here's a summary of correct terminology depending on the specific design constellation:

Applicability of Actual Table Terminology
Use CaseTable/Entity Term
General/AssociationsReferencing and referenced table
Aggregations/CompositionsPart and whole table
InheritanceSub and super table
TreesChild and parent table

If you really need a shorter term for referencing and referred tables, I suggest to use "source" and "target" tables. (Source and target are mutual antonyms whose notion is also used by build tools like GNU make, Apache Ant, or Phing.)

References for Terminology:

Last updated: 2010-11-10