1樓：劉強
第一專案前期一定要和業務溝通好，對業務要有自己的理解。第二設計的時候一定要把粒度控制的盡量小，不要嫌麻煩。第三一定要有專案變化的預期，做好擴充套件的準備。
2樓：史強
資料結構取決於你的取捨。
如果你想讓資料結構變的充滿彈性，那麼必然會對資料運算效率產生或多或少的影響。你需要平衡其間的效能損失。
資料結構一沉不變是肯定不可能的。
關鍵是你怎麼理解資料庫和資料結構？
舉個簡單的例子，你可以讓資料庫只儲存資料關係，而資料結構使用json這一類資料來表達。程式可以通過Json來自己增減資料持有和結構。
但是這樣的方式，會給資料庫關聯查詢製造負擔。比如，對某些指標在Json內部的資料，你需要額外的付出資料庫效能才能統計出來，並且，這樣做很可能不具備資料庫優化的條件。
當然，你可以取捨，對於那些可能不需要頻繁統計的資料字段，或者資料量較小的行為，適當的可以合併使用類似方法。
對於海量資料，這樣的做法是很不適合的。
海量的資料緯度分析，就不能用傳統的DBMS去做了。
這是另乙個話題了。
資料結構的變化一般分為兩種。
（1）在現有結構上迭代。
（2）新建的結構，並且必須相容老結構。
對於（1），你可以在設計上對表字段進行拆分或者合併。
對於（2），統計資料或者計算，最好並行執行，並利用中間表或者記憶體表合併結果集。
3樓：thelostworld
最好在開始的時候多調查，需求分析需要弄好，不然後期再改需求和業務邏輯很難，也話更多時間，業務需求，好友後面去業務擴充套件，這個是一方面還有就是選用什麼框架用什麼很重要
4樓：王璐
設計時就要想到、想好。不然乙個系統的壽命預期到8年，你要年年改資料庫麼？
而且這不是只是資料庫的問題，業務補充完善、互動重新設計……這個成本其實和重新設計沒啥區別。
如何理解「程式 演算法 資料結構」這句話？
小凡 本來想來找答案的，後來感覺還是把十幾年工作經驗簡單分享下。程式 資料結構 演算法，這句話呢，如果放在現實世界，有個簡單的小例子，假如有件事，我需要知道附近有多少個人。這個問題，在計算機的世界應該怎麼表達，首先應該有個地圖。地圖的組織結構就是資料結構了，然後就是怎麼找到這些人，這就是演算法。這裡...
react redux專案的協作中，如何解決state結構變動時可能造成的隱患？
Belt 看你維護的公共狀態是不是很多。如果多的話，其實就是可以考慮樓上所說的，利用connect跟reselect來做，以後維護reselect裡面的函式來，改動的地方就變得很少了， 通過中介軟體做資料清洗，維護state結構不變應該可以解決這種隱患吧，但是覺得沒必要所有的都做，有時候維護這些中介...
如何設計分銷系統中 多級使用者關係的 資料結構
泥丸子 以上下層級部門來說,方法一 使用mysql的FIND INSET函式。每個部門儲存所有上級部門的ID，如1,3,9,13,21。當部門資訊變化時，改變這個path的值。這樣查詢上下級都很方便。但是資料量大時FIND IN SET效率不高。方法二 建乙個父子關係表，欄位有grade,dptId...