problème de conception:

Question

Je construis un système de gestion des bénévoles et je vais avoir des problèmes de conception DB:

Pour expliquer le processus: Les bénévoles peuvent vous inscrire pour les comptes. Les bénévoles rapportent leurs heures à un projet (chaque bénévole peut avoir plusieurs projets). Les superviseurs bénévoles sont avisés lorsqu'un nombre d'heures de bénévolat se rapproche d'un certain montant pour leur donner une récompense.

Par exemple: un bénévole qui s'est porté volontaire pendant 10 heures reçoit un t-shirt gratuit. Le problème que j'ai est de savoir comment concevoir la base de données de manière à ce qu'un seul profil de récompense puisse être lié à plusieurs projets et avoir un seul profil de récompense «multi-niveaux». Une grande chose à ce sujet est que les structures de récompenses peuvent changer afin qu'ils ne peuvent pas être simplement codés en dur. Exemple de ce que j'entends par profil de récompense «multi-niveaux»: Un bénévole qui a fait du bénévolat pendant 10 heures reçoit un t-shirt gratuit. Un bénévole qui s'est porté volontaire pendant 40 heures reçoit un chèque gratuit de 50 $.

Les solutions que j'ai trouvées sont: Pour avoir une table de profil de récompense qui relie une rangée à chaque profil de récompense.

rewardprofile: 
rID(primary key) - int 
description - varchar/char(100) 
details - varchar/file (XML) 

En plus, tout en sur le sujet, peuvent entrées de champ DB être des fichiers?

OU

d'avoir une table de récompenses qui concerne une quantité prédéterminée et récompense où chaque ligne est la suivante et une seconde récompenses tableau profil qui les lie les récompenses entrées ensemble:

rewards: 
rID(primary key) - int 
rpID (references rewardsProfile) - int 
numberOfHrs - int 
rewardDesc - varchar/char(100) 

rewardsprofile: 
rpID(primary key) - int 
description 

si cela pourrait ressembler à:

rewardsprofile: 
rpid | desc 
rp01 | no reward 
rp02 | t-shirt only 
rp03 | t-shirt and check 

rewards 
rid | rpID | hours | desc 
r01 | rp02 | 10 | t-shirt 
r02 | rp03 | 10 | t-shirt 
r03 | rp03 | 40 | check 

Je suis sûr que cette question n'a rien de nouveau, mais mon fu google est faible et je ne sais pas comment pce Assure cela de manière significative. Je pense qu'il doit y avoir une solution plus formalisée que ma méthode (hack and slash). Si quelqu'un peut me dire ce que l'on appelle ce problème ou des solutions à ce problème, ce serait bien. Merci pour tout votre temps!

Cheers, -Jeremiah Tantongco

Answer 1

Ceci est une structure grossière de la façon dont je gérer cela:

Volunteers 
    volunteerid 
    firstname 
    lastname 

VolunteerAddress 
    volunteerid 
    Street1 
    Street2 
    City 
    State 
    POstalcode 
    Country 
    Addresstype (home, business, etc.) 

VolunteerPhone 
    volunteerid 
    Phone number 
    Phonetype 

VolunteerEmail 
    volunteerid 
    EmailAddress 

Project 
    Projectid 
    projectname 

VolunteerHours 
    volunteerid 
    hoursworked 
    projectid 
    DateWorked 

Rewards 
    Rewardid 
    Rewardtype (Continual, datelimited, etc.) 
    Reward 
    RewardBeginDate 
    RewardEndDate 
     RequiredHours 

Awarded 
    VolunteerID 
    RewardID 
    RewardDate 

Vous aurez probablement des récompenses limitées dans le temps, c'est la raison pour laquelle j'ai ajouté les champs de date. Vous devez ensuite configurer un travail pour calculer les récompenses une fois par semaine ou une fois par mois. Assurez-vous d'exclure ceux qui ont déjà receivced ce prix particualr si pertinent (Vous ne voulez pas donner un nouveau t-shirt pour 10 heures travaillées vous?)

Answer 2

Oui, les champs de base de données peuvent être des fichiers (type binaire, caractère grand objet, ou XML) en fonction de la mise en œuvre de la base de données spécifique.

La table rewardsprofile semble être difficile à maintenir si vous avez un grand nombre de récompenses différentes dans le futur. Une chose que vous pourriez envisager est une structure comme:

rewards: 
rID(primary key) - int 
numberOfHrs - int 
rewardDesc - varchar/char(100) 

volunteers: 
vID(primary key) - int 
.. any other fields you want here .. 

rewardshistory: 
vID (foreign key references volunteers) 
rID (foreign key references rewards) 

Chaque fois que vous voulez ajouter une récompense, vous ajoutez à la table de récompenses. Les anciennes récompenses restent dans la table (vous pouvez vouloir un champ 'actuel' ou quelque chose pour savoir si la récompense peut encore être assignée). La table des récompenses répertorie les récompenses qui ont été données aux volontaires.

Answer 3

Oui, les entrées de champ DB peuvent être des fichiers. Ou, plus précisément, ils peuvent être des fichiers de fichiers qui référencent des fichiers. Est ce que c'est vraiment ce que vous voulez dire?

Alors que nous sommes sur le sujet des champs de données qui référencent d'autres données, que savez-vous sur les clés étrangères? Que pouvez-vous accomplir avec des références à des fichiers que vous ne pourriez pas accomplir encore mieux en utilisant judicieusement des clés étrangères?

Les clés étrangères, et les clés auxquelles elles se réfèrent, sont des concepts fondamentaux dans le modèle relationnel des données. Sans ce modèle, votre conception de base de données va être assez aléatoire.

Answer 4

Matin,

Vous devez vraiment placer toutes vos tables sur un graphique déterminent ensuite les règles métier pour ce graphique dans le diagramme de relation d'entité. Une fois que vous décidez quelles sont les relations directes entre chaque table seulement, alors vous tester pour voir si vous obtenez les réponses souhaitées. Cette procédure est appelée conception de base de données et il semble que vous ne l'ayez pas encore fait mais que vous ayez devancé un peu de ce que je vois.

Il y a beaucoup de bons livres sur la conception de base de données sur le marché. Celui que j'utilise est "Database Design For Mere Mortals". C'est très facile à lire et à comprendre.

Espérons que cela aide.