Cette stratégie fonctionne à l'inverse de la stratégie SINGLE_TABLE. Plutôt que d'envoyer tous les champs de toutes les entités vers une table unique, on les envoie vers autant de tables qu'il y a de classes concrètes annotées @Entity dans la hiérarchie. On a donc autant de tables dans notre schéma que de classes concrètes annotées Entity dans la hiérarchie, c'est-à-dire en général moins que dans la stratégie JOINED. En revanche, on peut avoir des collisions de noms, étant donné que chaque table récupère des colonnes associées à des champs de ses super-classes. Notons qu'en toute rigueur, ce type de schéma est optionnel dans la spécification JPA 2.0. Par conséquent, certaines fonctionnalités peuvent être absentes de certaines implémentations.

Reprenons notre exemple précédent, en annotant notre classe Personne avec @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS). On obtient le schéma suivant.
On remarque que les tables Personne et Maire sont toujours présentes, c'est leur contenu qui change. La table Maire comporte maintenant deux colonnes nom et prenom, elle devient indépendante de la table Personne. De fait, sa clé primaire n'est plus une clé étrangère.

Cette stratégie présente un inconvénient principal : celui de mal supporter le polymorphisme. Cet inconvénient se manifeste de deux façons : sur les requêtes et les collections. Le traitement d'une requête qui demanderait toutes les instances de Personne, ou une sélection de telles instances, par exemple sur un critère portant sur les champs de Personne, requiert de faire une union entre toutes les tables associées à des entités qui héritent de l'entité Personne. Ces requêtes peuvent être très coûteuses. Le deuxième inconvénient porte sur les collections de Personne. Dans le modèle objet, une telle collection est déclarée naturellement : Collection<Personne>. En base, les instances de Personne sont réparties dans plusieurs tables. Le support pour les collections polymorphiques est donc déficient dans ce type de schéma.