Question

Un rapport peut contenir plusieurs graphiques. Le tableau Graphique se présente comme suit:

  • Graphique : Id , ID Chart , ID Rapport , ...

L'élément ChartId ci-dessus peut mapper sur ChartId vers un des types de graphique suivants:

  • Ligne : ChartId , Épaisseur , YAxis , XAxis , Couleur , ...
  • Tarte : ID Chart , Rayon , Couleur , ...
  • Barre : ChartId , Largeur , Couleur , Bordure , .. .

J'utilise SQL Server et malheureusement, d'autres solutions, telles que l'utilisation de CouchDB, etc., ne sont pas des options viables. J'ai également l'intention de mapper ces tables sur des entités utilisant Entity Framework.

Ce motif est mon premier essai et je vois plusieurs problèmes avec ce motif:

  1. Graphique . ReportId ne peut pas être une clé étrangère sur plusieurs tables. L'application d'un FK pose donc problème.
  2. Lorsque vous exécutez une requête SQL (ou Linq), vous devez exécuter deux requêtes pour obtenir le type de graphique, puis interroger cette table. Sinon, vous devrez exécuter une jointure sur toutes les tables pour obtenir les données du graphique.
  3. Lors de la jointure avec les types de graphique, ChartId dans ces tableaux doit être unique pour que Graphique . ChartId soit mis en un seul. Ligne . ChartId ou Barre . ChartId ou Graphique . ChartId .
  4. Mapper ceci avec EF sera délicat.

J'imagine que c'est un problème assez commun pour qu'il existe des solutions prescrites et des moyens établis pour le résoudre.

Suis-je sur le bon chemin avec le design? Et si oui, comment résoudre les problèmes ci-dessus (FK, jointure, identifiant unique sur plusieurs tables et mappage).

Solution

Cette answer est assez complet sur les stratégies. Et article de l'équipe SQL sur la implémentation de l'héritage de table dans SQL Server m'a conduit là où je voulais.

Était-ce utile?

La solution

Avez-vous envisagé de placer les graphiques dans le même tableau et d'utiliser un Tableau par héritage hiérarchique modèle? Le lien ici montre comment implémenter ceci dans Entity Framework. Que ce soit viable ou non dépend de la différence entre tous ces types de graphiques et du nombre de champs nécessaires à chacun.

Il existe également un tableau par type qui est plus similaire. à ce que vous décrivez déjà.

Autres conseils

Je m'attaquerais à cela avec un schéma d'héritage de table:

Chart (ChartId, ChartTypeId)
   PK (ChartId, ChartTypeId)
   CHECK ChartTypeId IN ('Line', 'Bar', 'Pie')

LineChart (ChartId, ChartTypeId)
   PK (ChartId, ChartTypeId)
   FK (ChartId, ChartTypeId) -> Chart
   CHECK ChartTypeId IN ('Line')

Pour ajouter un graphique, vous devez d'abord ajouter le " base " Tableau de graphique, puis dans le "sous-type" approprié tableau graphique. Les contraintes de vérification gardent tout en ligne.

Graphiques linéaires. Les camemberts et les graphiques à barres sont des formes spécialisées de graphiques.

Lookup " modélisation relationnelle de spécialisation de généralisation " pour de bons articles sur ce modèle.

  

Ou, je vais devoir lancer une jointure contre   toutes les tables pour obtenir les données du graphique.

Oui, et c'est bien.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top