本文轉貼自PTT
台灣最大的本土社群網站
分享這篇文章到Facebook、Google+或噗浪！
作者
AvatarH (Avatar Hsieh)
看板
Soft_Job
標題
Re: [閒聊] 資料結構不重要 ?
時間
Wed Jun 13 13:56:10 2012
───────────────────────────────────────
就工作經驗分享：
一、資料結構知識只是基本，如何運用於實務上才是重點。
如果曾管過將近百萬筆資料分散於數百個資料表，也許就會知道資料結構的重要了。
曾經，我在在類似汽車翻修廠的資訊部門待過，上面要求要將所有的車輛結構資訊化。
在每台車中，可以大略分為底盤，車身，電系，油系及液壓系。
這五大系統，每一個系統是由總成所構成，每一個總成可以再分為次總成，
次總成可以再分為次總成，次總成分到不能再分時，就稱為零件。
所以，每一個總成要分幾次（層）才能成為零件都不相同，而且不知道。
而每一次分解都會產生次總成及零件。
在一個總成中相同的零件會用在不同層的次總成中，且數量不一定。
不同系統中的總成也有可能會使用相同的次總成及零件。
其中的一個商品展開成為零件時有八萬多個零件。
對於這個問題，我們是使用樹狀結構來解決的。但是我敢保證，
即使翻遍了所有的資料結構的書，沒有一本會告訴你怎麼處理這個問題，怎麼寫程式。
我們是用 Java 來完成這個系統的，Java 所提供的 container 和 Collection
都用了，但是只是拿來裝類別而已，
如何使用將零件組成車子的演算法，則是資料結構的應用。
如果有人說，那我只要知道資料結構的知識就好了，不需那麼辛苦重新發明輪胎。
我想，有實際寫過資結構程式的人感受會比較深切些。
例如，資料結構中的排序，就有泡沫、選擇、插入、謝爾...等，就經驗來說，
並沒有一種排序方法適用於所有的資料特性。例如隨機產生100個 0 ~ 100 之間，
或 0~10^6 之間的整數，由於演算法的不同，我們就會用不同的排序。
第一種情形，我們用100個箱子裝隨機亂數的個數，就算用泡沫排序時，
複雜度也不過 n^2。但第二種情形如果用 10^6 個箱子，那麼系統效能必定不好，
所以勢必要換演算法，所以也會用不同的排序方法。
二、SQL 查詢命令最好根據資料庫特性撰寫。
把車子結構樹狀化的目的是為了申請零件，由於常發生零件申請量不足的問題。
這是由於每個總成都有專門部門負責維修的，一個部門可能要修很多種不同的次總成。
然後，相同的零件可能會用在單一部門所維修的不同次總成中，
或不同部門維修的次總成。所以零件的需求量常估錯。
因為每個部門底下還有不同小組，每個小組只知道自己的需求，
還有修護人員為了修護方便常常會私屯零件，所以超量申請。
例如一台車子只有四個輪胎，卻申請五個。
為了處理這個問題，我們從前面的結構系統中跑出這個部門的已申請、待撥、
、欠撥、已撥，及申請時的申請數上限。
這些都需要對資料庫做查詢，由於系統的資料筆數非常多，所以有時查詢非常慢。
所以我們發現到，資料庫查詢指令必須依照資料庫特性來寫。
例如，查詢結果的資料有循序性，或部分連續性，或沒有連續性，相同的 SQL Statement
將會造成不同的執行效能。
所以後來，雖然都是查詢，但 SQL 語法卻不盡相同，都會上系統調教才確定。
通常 DBA 都是資深的 Coding 人員轉的。
當然資料庫效能和資料表的正規化和關聯性也有很大關係，但不多贅述。
三、系統演算法的效能很重要
由於開發系統的通常是資訊部門，所以擁有最好的電腦是理所當然的，
在開發過程中，硬體效能的瓶頸是幾乎感受不到的。
但是，系統總有一天會上線，只要系統夠大，硬體瓶頸就會感受到了，
我原來的公司有將近百台電腦，如果因為系統要上線，所以建議老闆要將公司
的所有電腦更換，我想下場會很慘吧。而且使用者給太好的設備其實意義不大，
只會被拿來做對工作產能沒有幫助的事。
也不能要求老闆買一台超級伺服器來跑系統吧。再說再強的伺服器也有極限的。
所以在系統開發的過程，我們就不斷的修改演算法，以增進系統效能。舉例來說，
第一部分的樹狀結構，我們從第一版的30秒以上產生樹狀結構，到定版的5秒以內
（從按下瀏覽器的按鈕到結構圖顯示完畢），才達到一個可接受的系統效能。
希望這些經驗能有所幫助。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.118.170.15
推
sawang
:推經驗分享
06/13 16:13
推
jain00
:好棒的分享，筆記中~
06/13 17:47
推
yauhh
:「系統開發的過程，我們就不斷的修改演算法」我欣賞這句
06/13 18:09
推
ihon822
:自己刻BOM表 好強大...
06/13 18:15
→
bleed1979
:修改演算法也許免不了，如果是不斷修改，
06/13 20:16
→
bleed1979
:那一開始設計的人到底是怎樣。
06/13 20:16
→
yauhh
:我猜因為具體資料量大幅成長後,思考演算法的幅度也改變了.
06/13 20:17
推
thinkniht
:同意樓上
06/13 21:47
推
hanbz
:因為沒有最好只有更好啊XD~往好方向改是好事~
06/14 12:46
→
AvatarH
:我們是從無到有，料件書掃描後OCR才產生BOM表
06/14 12:46
→
AvatarH
:所以結構部分沒有原來的系統。
06/14 12:47
→
AvatarH
:更正，料件書掃描產生料件清單，我們寫程式轉成BOM表.
06/14 12:49
推
tomap41017
:請問這些每個車廠都要做一次嗎？
06/15 19:42
→
viper9709
:推~~很難得且實用的經驗~~
06/16 00:08
→
AvatarH
:回T大，我們是一個小組做，大約3到5人寫程式，
06/18 13:06
→
AvatarH
:但資料的校對是各部門做(只要對Excel和料書)就可以了，
06/18 13:07
→
AvatarH
:結構系統產出的正確性則是由修護部門確認。
06/18 13:09
推
katiowa
:好棒的文章
06/21 20:04
----本文使用PCMAN+BBI轉貼----
※ 新版PCMAN開放測試中，新增功能：
自動登入PTT
PTT全文搜尋
分享PTT文章到Facebook、噗浪與Google+
預覽影片與圖片
用PCMAN+BBI連回
PTT原文
