學生考試期，終於能輕鬆一下，介紹一下音樂投票系統的數據庫，只是在白紙上草草畫了一下ER圖，作為一些初稿，不過還是距離成品需要很多修改，因此還是決定不發佈database，之作分析，因為你的功能決定你的數據庫。
1. 首先筆者由音樂資料入手，定義音樂的各種資料，作為一個music table，至於有甚麼field，在此列出參考：
m_id,m_title,m_album,m_artist,m_compose,m_lyrics,m_category,m_company,m_file,m_cover,m_date
音樂的field內容，建議參考音樂網站，例如itunes，amazon，根據其所有的音樂資料建立field。 這些field 會用甚麼類型，那麼大家就要思考一下。
2.根據上面的音樂資料，需要建立不同的table，包括
artist：歌手資料，介紹這個歌手或樂隊，當然可以好簡單，只有一個artist_id 和text field就可以，視乎你有何功能去介紹，artist_id 會與存入music table 中的m_artist
參照上面artist的例子，可以建立category, company等資料，基本上都是同一樣的東西
3.音樂資料好了，投票的人呢？因此需要會員資料user，當然有些人說不一定需要收集個人資料，不過一個比較合理的投票系統，作為一個音樂公司要設計的投票系統，收集一點資料作為審核準確性是需要的(報告記得寫收集資料有甚麼作用，很大商業作用的)
u_id,u_name,u_chi_name,u_en_name,u_sex,u_birth,u_phone,u_email
這些資料要人填是很麻煩，就算填也未必準確，但現在有一樣東西叫openid，例如facebook, google plus， 都可以作為同步登入。這些同步登入系統可以直接通過授權(重要)，取得使用者的個人資料，包括：名稱，性別，朋友，email等，詳細可以取得什麽資料需要看看每個開發商的資料。但假如你用這個功能，那麼你就需要加多幾個field或者是開一個table裝，token，key，session 等資料，這些資料是用來作為跟facebook, google 認證的。 但這些功能不一定要有，假如你需要與時並進，可以加上，可能有分加。
4.投票題目question，筆者設計的投票問題能簡單，一條問題，幾個選項，投完，顯示下一條問題，直到用戶離開或者沒有問題為止。
分析一下這個表，1個問題，有幾個選項，因此每個選項需要儲存問題的id，這是一個1對多的關係。
用戶投票了，投了哪個呢？那麼要記住用戶id，這個選項的id，也可以順手儲存問題id，可以節省合併查詢的煩惱。這些東西用來判斷用戶是否已經投票。
q_id, q_title q_description
option_id, question_id, option_description option_musicid
user_id,option_id,q_id,datetime
投票功能主要完成。假如你想要有不同的選項功能，那麼就要把Option 繼續分拆開來，或者option 分多一個type的field，不過儘量簡單省時間最好。像apple app store，只評積分而已。
5. 系統信息，config
這個就是紀錄網站設定，例如網站名，一些設定資料開關等，根據個人興趣設定，這些也可以不必進入database，可以用一個xml文件裝著。
假如你需要分析很多資料，那麼就要在相應的地方 加上field 來分析。
最後，還是那一句，把報告做好，不是你的database，只要database邏輯上不錯，功能上能實現，那麼就可以了。文字報告最重要，記得在每一樣功能上多粉飾。更重要的是需要站在商家的立場去思考，因為投票就是爲了取得對商家有利的資料，然後又將資料整理完發佈一些吸引其他用戶。
考好個拎B的試，好過你做份A project，試場才是最重要的。
rterter