2014-08-31 4 views
0

Dans ma langue principale (C#), il est très facile d'extraire des classes de données. Par exemple:Encapsulation ou abstraction dans la conception d'une base de données

public interface IFruit 
{ 
    public TimeSpan GrowthTime { get; set; } 
    public string Color { get; set; } 

} 

public class Apple : IFruit 
{ 

    public TimeSpan GrowthTime 
    { 
     get 
     { 
      throw new NotImplementedException(); 
     } 
     set 
     { 
      throw new NotImplementedException(); 
     } 
    } 

    public string Color 
    { 
     get 
     { 
      throw new NotImplementedException(); 
     } 
     set 
     { 
      throw new NotImplementedException(); 
     } 
    } 
} 

Comment iriez-vous implémenter ce type de fonctionnalité dans une conception de base de données? Disons que j'ai une table nommée Bulletins qui peut contenir plusieurs types de bulletins, qu'ils soient Announcments, Ads ou Events.

I pensé à créer une table Bulletins et une table séparée pour chacune des classes ci-dessus avec une colonne pour chaque FK contenue dans la table Bulletins; cependant, cela ne fonctionnera pas puisque les FK sont obligatoires (ou plutôt une mauvaise pratique si les annuler) et un Bulletin ne peut jamais être plus d'une des classes listées ci-dessus.

Je pourrais faire des tables séparées pour chacun d'eux mais la vue de modèle externe de l'utilisateur est seulement celle du Bulletins. Pour eux, ils voient un bulletin qui peut être un type différent, et non une entité distincte. Aucune suggestion?

Répondre

1

sont (pratique ou plutôt mauvais si les réduire à néant) obligatoire de FK

qui est en fait pas vrai. Il est parfaitement légitime d'avoir une clé étrangère NULL pour modéliser le parent "optionnel". Bien que vous n'en ayez pas nécessairement besoin pour l'héritage.

héritage est pas pris en charge en mode natif dans les bases de données relationnelles d'aujourd'hui, donc il est « non-concordance d'impédance » entre POO et base de données qui doit être surmontée, et il y a couple of ways de le faire, aucun d'entre eux idéal. Mon approche par défaut serait probablement "class per table" avec l'application de l'exclusivité et de la présence des enfants au niveau de l'application, et ne regarder d'autres approches que s'il y a une raison spécifique à cela.


connu également dans la modélisation de base de données comme « catégorie » ou « hiérarchie de généralisation » ou « sous-classement ».

Questions connexes