HNU_團隊項目_數據庫設計感想_我的感想

數據庫設計感想  我的的一點心得體會

---

 

 

最重要的放在最前面——討論開會時的123經驗

1. 開會前對會議目的及方式要有所考慮；

2. 不要隨意無目的開會；

3. 遵照時間，控制會議時間長度；

4. 會議主持人要維持會議只需，有明確決定的責任；

5. 避免會中插入無關話題；

6. 調動積極性，儘可能把會議開得生動活潑；

7. 主持人對發言進行小結；

8. 發言簡明扼要，一次只談一件事，最好有時間限制；

9. 會議結束後，主持人要和全員覈定會議結論；

10. 主持人應該對會議記錄負責，進行審覈或撰寫；

11. 必要時，將會議報告發給與會者。

以上摘自《廣西日報》，略有改刪。

 

---

　　

　　在數據庫設計時，咱們和指導老師周老師，還有負責教咱們的數據庫設計的尹老師，交流了不少次，給了咱們不少寶貴的意見，好比，表的結構方面應該邏輯清晰，針對需求進行表的設計，要考慮需求點是否真的可行有效。

　　這也很大程度上推動了咱們數據庫設計的進度以及設計方案的改良。由於數據庫的設計會直接影響到頁面數據的顯示的操做難度，因此咱們在設計時也是再三斟酌。

 

圖表 1 噪聲數據與用戶關係表

　　針對咱們的系統核心，也就是噪聲數據的存儲表，咱們也是十分慎重，花費了不少時間來考慮其構成。考慮到地圖顯示和曲線生成，咱們將原始數據存入噪聲數據表，每一個5s記錄一個噪聲信息；考慮到用戶上傳記錄的增刪改查，咱們又設計了上傳記錄表；再考慮到地圖標識的巨大運算量，咱們決定不進行實時更新，而採起存儲地圖標識的相關數據的方法來提升運行速度……

　　值得一提的是，咱們在商討用戶上傳信息的記錄時，我提出直接存儲某段錄音的最大值，最小值和平均值，雖然在討論中認爲這個數據並無很大的做用，並不可以體現出某些場景的具體信息，想要刪除此表，可是通過需求分析後發現，對於手機用戶，這個數據多是最有用也是最直觀的。抓住這個點，咱們最後定下了以下的表結構，完成了此部分的數據庫設計。

 

圖表 2 用戶上傳記錄表

　　歸根到底，咱們在數據庫設計上採起的方法是：

 「

　　針對某一頁面進行思考：它須要呈現哪些數據？數據庫中應該存儲哪些數據？頁面和數據庫之間的操做邏輯是否簡單和明確？

　　在此基礎之上，進行表的增刪以及字段與數據類型的設定。

 」

    諸如此類的討論還有不少，此處就再也不一一列舉。

    經過這些邏輯性，合理性的思考，咱們在討論中提升了本身思惟的嚴謹性，更強化了咱們對於本身的觀點進行清晰表達的能力！

    我相信，此次團隊項目中得到的經驗必定會讓我在當下收穫，將來受益。