héritage de table unique (avec Ebean + Play!cadre)

Question

J'utilise le concept de single table inheritance à cause de considérations de POO bien sûr.
Par exemple, PostLike et TopicLike hériter de Like classe.
Je vois deux problèmes avec cette méthodologie :

1. au lieu de deux tables (PostLike et TopicLike), j'obtiens "une grande table" de likes.
2. ce tableau a une colonne supplémentaire appelée type qui permet l'identification des enregistrements (c.-à-d.genre de like).à long terme, cela pourrait être un énorme gaspillage d'espace disque.n'est-ce pas ?

Je ne suis pas un expert en base de données et c'est pour cette raison que je voulais avoir votre avis sur la conception de cette base de données et savoir si ces deux problèmes sont cruciaux ou non.

Answer 1

Si vous n’avez qu’une seule table au lieu de deux, les lectures seront plus rapides, car vous éviterez les « jointures ».Mais vous utiliserez plus d'espace car vous aurez une colonne "dtype" supplémentaire et quelques colonnes vides.

Prenons un exemple.Voici le modèle (sans les annotations JPA) :

public abstract class Like {
    public Long id;

    public String foo;
}

public class PostLike extends Like {

    public String post;
}


public class TopicLike extends Like {

    public String topic;
}

Tu auras la table Like:

----------------------------------
|dtype | id | foo | topic | post |
----------------------------------
|post  |  1 |   a |  NULL |   p1 |
|topic |  2 |   b |    t1 | NULL |
----------------------------------

Et comme vous pouvez le voir, pour un élément « PostLike », vous aurez une valeur « sujet » NULL.

Mais de nos jours, l’espace disque n’est pas un réel problème.

Le seul défaut que je vois avec l'héritage de table unique est le nombre de colonnes qui peut être énorme si vous avez beaucoup de propriétés, et il est plus difficile d'ajouter une nouvelle propriété/colonne dans votre modèle (si vous devez appliquer une évolution de base de données) .

Et autant que je sache, ebean prend uniquement en charge "héritage de table unique".