1、表結構設計上的一些思考
在最初開始開發的時候，並沒有做更多的思考，乙個審批流程只有兩張表，一張儲存申請單資訊（包括當前審批狀態），另一張儲存審批過程中每級審批結果。但是當我寫第三個審批流程的時候，發現每張申請單中會存在一些相似的資訊，比如：是否提交、是否通過、審批是否結束、退回次數、下一審批人等等。每次新建申請單對應的表時都要加上這些字段，感覺麻煩的要死，所以就把這些字段單獨處理成為一張表（狀態表）。在**中專門寫乙個方法，當頁面第一次提交申請單時，後台會在狀態表中新增一條資料並返回主鍵儲存到申請單對應的表中，瞬間感覺減少了我很多的工作量。
以前看到過一片文章，說是當我們查詢資料時，欄位越少，效率越高。更新時，修改的字段越少，效率越高。盡量把動態資料和靜態資料進行分離。這裡靜態資料就是申請表，當提交申請後，這裡資料就不允許進行修改，最多在退回的情況可以再次修改。動態資料當然就是狀態表了，在整個審批過程中這裡的資料會經常變化，所以單獨處理會非常好。
2、程式設計上的一些思考
以上思考都是仁者見仁智者見智，也許過個幾個月，我學到一些新東西，感覺這些優化也不是太好，所以僅供參考，不必當真。
關於程式設計的一些思考
1 其實高階語言和面向過程的語言最求的目標都是一致的，高可復用性，另外，封裝性。我發現自己在寫c語言的時候，總是不自覺地就引入了高階語言的一些封裝性的思想 如以下 段1所示 而我的同學卻總是按著最原始的方式對函式進行命名。學過編譯原理的同學就會知道，最原始的c 編譯器其實就是將c 轉化成c語言，然後...
關於程式設計的一些思考
1 其實高階語言和面向過程的語言最求的目標都是一致的，高可復用性，另外，封裝性。我發現自己在寫c語言的時候，總是不自覺地就引入了高階語言的一些封裝性的思想 如以下 段1所示 而我的同學卻總是按著最原始的方式對函式進行命名。學過編譯原理的同學就會知道，最原始的c 編譯器其實就是將c 轉化成c語言，然後...
程式設計的一些思考
以後對程式設計的一些感觸，再次彙總總結，不斷迭代完善。b 如何衡量乙個產品或需求的價值？b 能幫助多少人，能幫助多大的忙 能持續幫助多長時間 b 如何衡量乙個產品設計的好壞？b 隨著產品的發展，增加乙個需求需要的時間越來越少，反之要重新設計了！b 為什麼設計比較難？b 總被忽略糊弄過去，沒有配套制度...