2010年12月29日 星期三

[閒聊]delicious 可能會不見?

這不是一個好消息 delicious 可能會不見。

http://uniquehazards.tumblr.com/post/2377362882/we-can-save-delicious-but-probably-not-in-the-way-you

我在 delicious 上面有 1043 個書籤。是念研究所開始累積的。

除了有很多是研究學術用的連結,也有很多是寫程式研究的連結,有更多,完全是宅男要用的…

delicious 是一個管理網路書籤的網站。
除了自己管理之外,也可以看別人是如何管理書籤的。
這是屬於一個集體智慧的社群網站,或許你平常不會去注意。
你可以看到在這個網站上的集體智慧顯露在標籤上(也就是關鍵字)。

我管好自己的書籤,提供了我的智慧結果,別人也是。
從系統方或是有志之人就可以從人與標籤與網址之間的關聯看出一些東西來。

說了這麼多,真的是希望他不要被廢掉。如果真的被廢掉了,
那…也許我自己來做一個好了…。

2010年12月17日 星期五

[sqlite] index 加快了查詢速度

原本我的表格裡,只有單純的幾個欄位,沒有任何欄位有設定 key 屬性,
也都沒有設定流水號的欄位。

要檢查資料是否有重覆的時候,我就得自己準備了一個 sql 字串來檢查,
到了資料有 22 萬筆的時候,大約查一次要 0.2 秒。
insert 或 update 一次只要 0.001 ~ 0.0017,看硬碟忙不忙。
如果有 14 萬筆資料,就要花 7 個小時在檢查資料重覆性。
塞一年的股票資料就很花工夫了。

後來查到網路上說,資料庫的 index 若有建立,可以省下很多時間,
當下試試看。

語法是:

create unique index if not exist <indexname> on <tablename> ( <keycolumn>, )

做完之後,馬上查詢的時間一次只要 0.001 秒,甚至有時少於 1 毫秒。

真省時間!

玩 database 還真麻煩。
這種事感覺是很基本資料庫優化的工作,應該要預設開啟的?
或是因為我沒有設 key column 引擎也不知道要怎麼幫吧。

這次以後就要對於 table schema 及 index 特別注意了。

ref:
http://www.sqlite.org/lang_createindex.html