數據庫設計問題：

我建立一個志願者管理系統，我有一些數據庫設計問題：數據庫設計問題：

爲了解釋這一過程：志願者可以註冊帳戶。志願者將他們的時間報告給一個項目（每個志願者可以有多個項目）。當幾個小時的志願者人數已經接近一些規定量給他們一個獎勵志願者監督員通知。

例如：誰已經主動10小時志願者接收免費的T恤。

我遇到的問題是如何設計數據庫，使得單個獎勵配置文件可以與多個項目相關聯，並且具有單一獎勵配置文件「多層次」。關於這一點很重要的一點是獎勵結構可能會發生變化，因此他們不能被硬編碼。

我的意思是「多層次」獎勵簡介的例子：自願參加10小時的志願者會收到一件免費的T恤。誰志願四十個小時，志願者收到$ 50升值檢查。

我拿出自己的解決方案是：爲了有涉及一個行到每一回報狀況的獎勵概況表。

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

另外，就在這個話題上，DB字段條目可以是文件嗎？

成具有涉及一個預設量的獎勵表和獎勵，其中每一行是如下和結合它們的回報的第二獎勵簡檔表項一起：

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

rewardsprofile: 
rpID(primary key) - int 
description

所以這可能看起來像這樣︰

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

我敢肯定這個問題是沒有新的，但我的谷歌福是薄弱的，我不知道如何phr以有意義的方式提出這個問題。我認爲必須有比我的（黑客和斜槓）方法更正式的解決方案。如果任何人都可以指導我解決這個問題或者解決問題的方法，那麼這個問題就會很大。感謝您的所有時間！

乾杯， -Jeremiah Tantongco

來源

2010-02-17 Zigu

你有沒有看看databaseanswers.com可能存在的模式？ – 2010-02-17 06:50:51

這是我將如何處理這個粗糙結構：

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

你可能有一定的時間限制的獎勵，這就是爲什麼我添加了日期字段。然後你會設置一個工作來計算一週一次或一個月左右的獎勵。確保排除那些誰已經receivced是particualr獎，如果相關（你不想給一個新的T恤的工作，每10小時，你的？）

來源

2010-02-17 14:42:09 HLGEM

是，數據庫字段可以取決於特定數據庫的實現文件（類型的二進制，字符大對象，或XML）。

的rewardsprofile表看起來像它可能是一項挑戰，以保持如果你有大量的未來有不同的獎勵。有一件事你可能會考慮的結構是：

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)

任何時候你想添加獎勵，你將它添加到獎勵表。舊的獎勵留在表（您可能需要一個「當前」場或某事跟蹤是否獎勵仍然可以分配）。獎勵歷史表跟蹤哪些獎勵已發放給志願者。

來源

2010-02-17 06:59:36

本質上是一個xref表。打敗我吧。 – 2010-02-17 07:01:34

是的，數據庫字段條目可以是文件。或者更準確地說，它們可以是引用文件的文件規範。這是你真正的意思嗎？

雖然我們討論的是引用其他數據的數據字段，但您對外鍵有多少了解？通過明智地使用外鍵，您可以通過引用您無法完成的文件來完成什麼？

外鍵和它們引用的鍵是關係數據模型中的基本概念。如果沒有這個模型，你的數據庫設計將會非常隨機。

來源

2010-02-17 13:43:05

上午，

你真的必須把圖表上的所有表格然後在實體關係圖中確定該圖表的業務規則。一旦你決定每一張桌子之間的直接關係是什麼，那麼你會測試一下，看看你是否得到了理想的答案。這個過程被稱爲數據庫設計，看起來你並沒有那樣做，但是從我所看到的有點超前你自己。

市面上有很多關於數據庫設計的好書。我使用的是「單純的凡人數據庫設計」。閱讀和理解非常容易。

希望這會有所幫助。

來源

2014-03-20 11:52:49 user1683732

數據庫設計問題：

回答

相關問題