2009-11-22 3 views
1

Je suis en train de mettre en place un schéma pour une base de données. Le but de la base de données est de suivre les applications dans notre département. J'ai un problème répété que j'essaie de résoudre. Par exemple, j'ai une table "Applications". Je veux garder une trace si une application utilise une base de données ou un système de suivi des bogues si en ce moment je champs de la table Applications appeléConception de la base de données - Ai-je besoin de l'un des deux champs de base de données pour cela?

Tableau: Applications
UsesDatabase (bit)
database_id (int)
UsesBugTracking (bit)
BugTracking_ID (int)

Tableau: bases de données:
id
nom

Tableau: bugtracking:
id
Nom

Dois-je consolider les « usages » colonne avec les colonnes d'identité respectives donc il n'y a qu'une seule colonne de suivi des bogues et une seule colonne de base de données dans la table des applications ?

Une bonne pratique ici pour la conception de base de données?


NOTE: (. Même si je suppose que soit l'approche pourrait générer ces données) Je voudrais exécuter des rapports comme « Pourcentage d'application qui utilisent le suivi des bogues »

Répondre

4

Vous pouvez supprimer les champs "uses" et rendre les colonnes id nulles, et laisser une valeur nulle signifie qu'il n'utilise pas la fonctionnalité. C'est une façon courante de représenter une valeur manquante.

Edit:
Pour répondre à votre note, vous pouvez facilement obtenir que les statistiques comme celle-ci:

select 
    count(*) as TotalApplications, 
    count(Database_ID) as UsesDatabase, 
    count(BugTracking_ID) as UsesBugTracking 
from 
    Applications 
0

solution fonctionne soit. Cependant, si vous pensez que vous voudrez peut-être simplement obtenir une liste d'applications qui n'ont/n'ont pas de bases de données/bugtracking considèrent que le fait d'avoir les champs de drapeau réduit la requête par une (ou deux) jointures.

Avoir les champs de bits est légèrement dénormaliser, que vous devez garder deux champs synchronisés pour garder un morceau de données mises à jour, mais je tendance à les préférer pour les cas comme celui-ci pour la raison que j'ai donné dans le paragraphe précédent . Une autre option serait d'avoir le champ nullable, et mettre null dedans dedans pour les entrées qui n'ont pas DB/etc, mais alors vous rencontrez des problèmes avec des contraintes de clé étrangères.

Je ne pense pas qu'il existe un moyen suprême, il suffit de considérer les compromis et d'aller avec ce qui est logique pour votre application.

0

Je voudrais utiliser 3 tables pour les objets: application, Database et bugtracking. Ensuite, j'utiliserais 2 tables de jointure pour faire des jointures 1-à-plusieurs: ApplicationDatabases et ApplicationBugTracking.

Les 2 tables de jointure auraient à la fois un ID application et l'ID de l'autre table. Si une application utilisait une seule base de données, un seul enregistrement ApplicationDatabases les regroupait.En utilisant cette configuration, une application peut avoir 0 base de données (aucun enregistrement pour cette application dans la table ApplicationDatabases) ou plusieurs bases de données (plusieurs enregistrements pour cette application dans la table ApplicationDatabases).

+0

L'OP a déjà un 1-to-many relation, ce que vous suggérez est une relation plusieurs-à-plusieurs. – Guffa

+0

Je peux voir pourquoi vous dites cela, mais il n'est peut-être pas nécessaire dans le modèle. – gbn

1

Pourquoi ne pas se débarrasser des deux Utilisez des champs et laissez simplement une valeur NULL dans les champs _id indiquent que le dossier ne pas utiliser cette application (suivi des bogues ou base de données)

+0

c'est ce que ma question est. est-ce votre recommandation ?? – leora

-1

Pour répondre à la question- modifié

Oui, les champs doivent être combinés, avec NULL signifie que l'application n'a pas une base de données (ou un bug tracker).

+0

pour # 1 et # 2, vous avez mal interprété la question, base de données et bug tracker sont complètement indépendants et ont des tables indépendantes comme indiqué ci-dessus. Je ne vous demande pas de combiner ceux-ci dans une colonne – leora

0

« Dois-je consolider les « utilisations » colonne »

Si je regarde votre relevé de problème, alors il n'y a pas non plus colonne « utilisations » du tout, ou il y a deux. Dans les deux cas, il est faux de parler de la colonne "THE". Puis-je poliment suggérer que vous apprenez à être précis lorsque vous posez des questions?

+0

tout d'abord, vous avez pris une partie de la phrase ici. J'ai dit que vous devriez consolider la colonne uses avec la colonne ID. . . Je l'ai changé pour être plus explicite mais puis-je poliment suggérer que vous lisiez la question complète pour le contexte – leora

0

Oui, l'utilisation de null dans les champs de clé étrangère doit être correcte - il semble superflu d'avoir les champs de bits. Une autre façon de le faire (bien qu'elle puisse être considérée comme mauvaise par les gens de la base de données ^^) est de les mettre par défaut à 0 et d'ajouter une ligne de données ID 0 dans les deux tables de bogue et de base de données avec un "Aucun". .. quand vous faites les rapports, vous devrez faire un peu plus de travail à moins que vous ne présentiez les valeurs "None" avec un pourcentage net ...

Questions connexes