Cette approche consiste à enregistrer toute une hiérarchie de classes dans une table unique associée à la première classe (en partant de la classe Object) annotée par @Entity. Cette table doit donc comporter des colonnes pour tous les champs de toutes les classes de la hiérarchie, du moins celles annotées par @Entity ou @MappedSuperClass. On prendra donc garde aux éventuels problèmes de collisions de nom au niveau des colonnes. Cette table enregistrera toutes les instances de ces classes : en général plusieurs instances peuvent donc cohabiter. Il n'y a pas d'autre moyen pour discriminer ces instances que de créer une colonne technique, afin d'enregistrer de quelle instance il s'agit, pour chaque ligne. Il est possible qu'une ligne donnée de cette table n'utilise pas toutes les colonnes définies. Dans notre exemple, toutes les instances de Personne auront une valeur nulle dans la colonne de jointure Bateau.

Prenons l'exemple du modèle suivant : une classe Personne est étendue par une classe Maire. La classe Maire définit une relation vers une Commune.
On choisit une stratégie SINGLE_TABLE. Cette stratégie est indiquée par l'annotation @Inheritance. Cette annotation ne peut être posée qu'une seule fois par hiérarchie de classe, sur la classe qui sert de racine à cette hiérarchie. On redéfinit ici le nom de la colonne technique qui va nous permettre de discriminer les instances de Personne et les instances de Maire dans cette table, par l'annotation @DiscriminatorColumn. De même, cette annotation ne doit être posée qu'une seule fois sur toute la hiérarchie. Enfin pour nos deux entités Personne et Maire, on définit la valeur utilisée pour discriminer les instances, par l'annotation @DiscriminatorValue. Examinons le schéma obtenu.
On remarque la présence de la colonne TYPE_ENTITE dans la table Personne, de même que la colonne de jointure commune_id, définie par l'entité Maire.

Cette approche présente deux limitations : sur le nombre de colonnes d'une part, et sur la sémantique de chaque colonne. Cette approche fonctionne bien si la hiérarchie de classe à enregistrer n'est pas trop profonde, et si l'on n'a pas trop de champs dans cette hiérarchie. Dans le cas contraire, outre les collisions de noms à gérer, deux problèmes peuvent survenir, qui peuvent rendre cette stratégie impossible à utiliser. Effectivement, cette approche peut mener à un très grand nombre de champs dans la table d'enregistrement. Or, les serveurs de base de données imposent une limite au nombre de colonnes qu'une table peut comporter. De plus, une deuxième limite existe, plus subtile : chaque ligne doit tenir dans un espace mémoire limité. Cet espace mémoire peut être rapidement dépassé si l'on a trop de colonnes de grande taille, comme des VARCHAR de tailles importantes. Par ailleurs, il faut garder présent à l'esprit que chaque ligne de cette table aura en général un certain nombre de colonnes nulles. Il faut donc être très prudent lorsque l'on ajoute des contrainte du type not null ou optional=false sur certaines colonnes. Dans notre exemple, il n'est pas possible d'ajouter une contrainte pour rendre obligatoire la relation Maire - Commune. Cette contrainte se traduirait par une commande SQL not null sur la colonne commune_id, or cette colonne va porter des valeurs nulles pour toutes les instances de Personne qui ne sont pas des Maire.