我們在開發中可能會遇到這樣一類問題：
1 你需要分步驟錄入乙個幾頁資訊的大資料表
2 系統會根據輸入資料根據某種規則分析出結果報表
3 結果需要持久化
4 結果可以修改
5 結果報表可以根據規則重新生成
6 每個輸入有唯一的乙個對應的報表
7 分析規則是容易測試的
problem
使用者記錄整個過程的表，每次處理都有這麼一張表：
account_id, 使用者id
input_id, 輸入
output_id, 輸出
stage, 目前階段（等待輸入，輸入完畢，處理完畢）
problem_version 版本
storagesource
用於儲存錄入資訊，所有資訊可以都儲存在乙個表裡（橫表），這種方法最大的問題就是無法動態的修改或者增加題目，好處是簡單，對於輸入相對穩定的人來說可以採用橫表設計。對於動態要求較高的採用豎表比較合適。
如果採用橫表，欄位為
quest1,quest2....,questn...,profile_stage,created_at,updated_at
one_to_one problem
如果是豎表
problem_id, quest_key, quest_answer, created_at, updated_at
這種設計靈活，但是訪問操作相對複雜
many_to_one problem
readablesource
將storagesource表和其他資訊包裝到乙個readablesource表中，作為分析輸入依賴的唯一類
viewableresult
將分析結果全部輸出到view物件，作為輸出的唯一依賴
analyzer
將業務規則封裝到該物件，採用builder模式來設計
builder.read(readable_source)
builder.build_first_stage
builder.build_second_stage
viewable_result = builder.viewable_result
storageresult
將輸入結果viewableresult持久化
演算法設計與分析 時間複雜度分析
t n co pc n t n c c n t n c op c n t n running time c op c co p execution time for basic operation c n number of times basic operation is executed thu...
系統設計分析
系統設計出來的好壞很大程度取決於使用者需求是否合理，當然還有就是完成專案的技術上是否有難度。在公司我剛做完乙個專案，當然是乙個非常小的專案。雖然是乙個小專案，但它五臟俱全。還有就是寫的系統是為公司自己用。就算是這麼小的專案也經過了兩次大的需求的變動。由於需求分析不由我本人來做，我的角色是專案開發者。...
演算法設計與分析 時間複雜度和空間複雜度分析
分析時間複雜度和空間複雜度1.演算法選用的策略 2.問題的規模 3.編寫程式的語言 4.編譯程式產生的機器 的質量 5.計算機執行指令的速度 演算法的時間複雜度取決於問題的規模和待處理資料的初態1.基本語句 基本語句是執行次數與整個演算法的執行次數成正比的語句，基本語句對演算法執行時的貢獻最大 2....