Re: [請益] 資料歸納

看板ask-why作者 (讀者)時間14年前 (2010/06/07 01:07), 編輯推噓1(1023)
留言24則, 2人參與, 最新討論串3/3 (看更多)
※ 引述《hihieveryone ( )》之銘言: : 我有將近 10萬筆的資料 可是是不同類型的 : 有文章 有圖片 有影片 小到連網址都有 .. : 可是我不太會收納 : 不知道有沒有什麼好的收納方式可以供參考呢 ? : 有人專門在研究電子資料收納的嗎 ? : thx 當然有,而且是一個曾經熱門過的技術潮流,事實上關心資訊科技的人應該都聽過, 只是可能因為是商業化的技術名詞而被忽視,這就是資料倉儲 (data warehouse) 。 資料倉儲的原始目的,就是讓企業可以簡單地堆積和保存資料,並有效地取用分析。 在實際的建構方法上,則有許多種不同的派別,其中最早發展出來也最簡單的做法, 稱之為資料超市 (data mart), 把每個可能有用的資料打上簡單的標籤描述和分類, 然後可以在資料的使用過程中做進一步的處理和分析。 當然,事情沒有這麼簡單,後面的發展和問題一大堆。 但是在概念上,就是我們無法預期資料如何被使用,所以就只能在資料匯入的初期, 以合於成本考量的方式,儘量讓資料結構化,往後再進一步地通過各種方法來調整, 而這樣的一個高度彈性的架構,是很不容易的,我們會需要做一些資料特性的假設, 來建構合適的資料倉儲系統。 例如以個人使用來說,多媒體資料可能佔了很大部分,於是就不能像企業資料一樣, 以大量的結構化資料來考量,目前的資料倉儲方法,可能就有很多不能適用的部分, 這可能就是一個商機所在,只是個人使用者一般不會為此付出高昂成本。 也因此,現在的軟體公司不會為此發展個人的資料倉儲系統,但主要技術已經有了, 未來也可能在技術成本和個人需求的考量下,在適當的時候出現。 而現在根據不同的資料格式做搜尋和標籤的技術,其實已經很夠了。 但未來在語意化資料模型 (semantic data model) 的發展下,多數資料在建置時, 就可能會帶有資料內容的描述,個人資料倉儲的需求也未必會持續增長到哪裡去。 至於實體的資料保存使用,像是 SAN 或 NAS 之類的技術一大堆,就不用多說了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.41.126.67

06/07 21:07, , 1F
你是要原PO為了整理檔案總管,再多架一個SQLserver就是?
06/07 21:07, 1F

06/07 21:08, , 2F
人家是要問檔案索引、分類這種圖書館學的東西
06/07 21:08, 2F

06/07 21:08, , 3F
大家越回答越扯...
06/07 21:08, 3F

06/07 21:40, , 4F
那倒不;這篇我覺得很切題.其實在專案分析時 top-down 或
06/07 21:40, 4F

06/07 21:41, , 5F
down-top 是會爭論不休的;爭論是因為根本做不出來在搶資源
06/07 21:41, 5F

06/07 21:41, , 6F
如果有一個強者能拍胸脯:我知道花多少錢多少時間保證做好
06/07 21:41, 6F

06/07 21:42, , 7F
那不管任何一種分析他都能用,也都會充滿說服力.
06/07 21:42, 7F

06/07 21:42, , 8F
top-down:從PM角度,想做多少東西開始切割功能,凡自己做不
06/07 21:42, 8F

06/07 21:43, , 9F
到的就發包出去;down-top:工程師就自己做得到的提出報告,
06/07 21:43, 9F

06/07 21:43, , 10F
並且要求PM不要提出太強大的產品需求.從以上兩者的比較來
06/07 21:43, 10F

06/07 21:44, , 11F
說,使用者反正什麼都不知道,連要花多少錢都不知道,比較像
06/07 21:44, 11F

06/07 21:44, , 12F
PM,需求丟出去在等別人喊價錢.
06/07 21:44, 12F

06/07 21:45, , 13F
我是屬於工程端,所以我會說我能做到什麼,超出的不談
06/07 21:45, 13F

06/07 21:46, , 14F
而做得到的是能力所及,代價能預估,才能夠詳談.就以架一個
06/07 21:46, 14F

06/07 21:46, , 15F
SQL Server 來說,我已經架過,我就可以談了;也就是我常說的
06/07 21:46, 15F

06/07 21:47, , 16F
"要縮小題目";其實原PO一直擔心的"服務公司倒閉則服務不存
06/07 21:47, 16F

06/07 21:47, , 17F
在",那也是他一直以為這些全是網際服務.其實自己架Server
06/07 21:47, 17F

06/07 21:48, , 18F
弄成自家的桌上服務,那根本就沒有倒閉的問題,那是他自己一
06/07 21:48, 18F

06/07 21:48, , 19F
直沒去看通的.如果我現在還有八位元的蘋果電腦,我當然必需
06/07 21:48, 19F

06/07 21:49, , 20F
保留 MarketPlan(八位元的excel),那是當然的啊!
06/07 21:49, 20F

06/07 21:50, , 21F
難道原PO必需學會寫程式,自己寫一套試算表嗎?
06/07 21:50, 21F

06/07 21:51, , 22F
把已經做好,能用的提出就已經夠了;至於圖書館學,或我說的
06/07 21:51, 22F

06/07 21:51, , 23F
資料庫如何規劃,那流派多,有專版,他得自己想法子.基本上如
06/07 21:51, 23F

06/07 21:52, , 24F
果我用編年,找封情書應該不必三秒.
06/07 21:52, 24F
文章代碼(AID): #1C2zMzNN (ask-why)
討論串 (同標題文章)
本文引述了以下文章的的內容:
完整討論串 (本文為第 3 之 3 篇):
文章代碼(AID): #1C2zMzNN (ask-why)