今天去吃阿松的喜酒.
時光飛逝,當年在補習班的那群常常惹我生氣的臭男生們,竟也一個個結婚了,大前年是小弟,前年是我,去年是堯堯,今年則是阿松,不知道明年又要輪到誰??算算日子,不知不覺與他們相識竟也超過15年了,哇~真是恐怖~~
當年的毛頭小子,而今各自在其工作領域中各據山頭,獨領風騷,今日的新郎倌阿松現在某知名電台任職專業攝影師,透過他的專業鏡頭捕捉,讓大家可以隨時知道最新的政治與其他重大社會新聞等;而他愛情長跑十餘年的新娘子,目前則是在大學任教的日文老師,今天真的好開心喔~終於看到他們倆的愛情長跑有了一個完美的歸宿,結婚是一個新的開始,也是一門很難修的課,希望大家都可以修好自己的學分,畢業時繳出一張漂亮的成績單,最起碼,也算是要對自己有一個交代吧,才不虛此行~
大家一起加油!! 也祝福阿松他們這對新人,新婚快樂,永浴愛河~
^_____^
2009年11月18日 星期三
osCommerce 架站
osCommerce 架站
星期一, 八月 31, 2009 | Author: 北海小英雄(外號土芭樂)
http://tbala.net/tBala3-0801.html
以下是 osCommerce 相關的資訊：
oscommerce支援站 網址：http://www.oscommerce.com/
KMD網站 網址：http://www.kmd.com.tw/index.php
資源站台：http://www.erufa.com/wp/archives/17
星期一, 八月 31, 2009 | Author: 北海小英雄(外號土芭樂)
http://tbala.net/tBala3-0801.html
以下是 osCommerce 相關的資訊：
oscommerce支援站 網址：http://www.oscommerce.com/
KMD網站 網址：http://www.kmd.com.tw/index.php
資源站台：http://www.erufa.com/wp/archives/17
2009年11月7日 星期六
十一月份慶生
原本是預計明天要到桃園竹圍魚港吃海鮮的,但因為將近一半的好友明天有事無法參加,於是決定取消明天的聚餐.但十一月份的壽星生日還是要過的.晚上十點左右才開始約人,在台北的好友們相約到小弟家幫十一月份的壽星:豬肉,東振,威鋼三人慶生,趕到小弟家已經是深夜十二點又過一分鐘了.其實感覺得出來大家身心都很疲憊,白天上班很累,晚上約會也很累,之後再被我一一call出來趕這一攤,真的好感動大家的有心.好友不正是如此嗎?再忙再累,這個重要的日子是不會缺席的.
也許,再過幾年,東振&威鋼也有交女朋友了,大家就不能再像現在一樣常相聚在一起聊天打屁什麼的.所以,我好開心,也好珍惜目前大家都還能夠聚在一起的美好時光. 嗯,現在已經是11/7凌晨3:43分了,祝福昨晚的壽星:東振&威鋼生日快樂,也祝福11/18的壽星:豬肉能夠跟寶貝珍有情人終成眷屬,恩恩愛愛直到永遠....
^____^
也許,再過幾年,東振&威鋼也有交女朋友了,大家就不能再像現在一樣常相聚在一起聊天打屁什麼的.所以,我好開心,也好珍惜目前大家都還能夠聚在一起的美好時光. 嗯,現在已經是11/7凌晨3:43分了,祝福昨晚的壽星:東振&威鋼生日快樂,也祝福11/18的壽星:豬肉能夠跟寶貝珍有情人終成眷屬,恩恩愛愛直到永遠....
^____^
2009年10月21日 星期三
漸行漸遠的心情....
昨晚收到威而鋼的回覆,心情有點不爽.所以這週末的宜蘭行,我確定不會去參加了.
突然有種感慨:覺得自從去年年底開完會後,大家感情好像變得愈來愈疏離了,再加上今年豬肉&ANT都有交女朋友了,他們的重心當然也是理所當然地都擺在自己的女朋友身上,也許是時間/空間的距離吧,最重要的是那次開會的不歡而散,雖然事後都沒有人再提起這件事,但我知道,在大家心底或多或少都有留下些許的疙瘩OR不舒服的感覺.所以,隱約中我也有些許地感覺到:那是一種漸行漸遠的心情....
突然有種感慨:覺得自從去年年底開完會後,大家感情好像變得愈來愈疏離了,再加上今年豬肉&ANT都有交女朋友了,他們的重心當然也是理所當然地都擺在自己的女朋友身上,也許是時間/空間的距離吧,最重要的是那次開會的不歡而散,雖然事後都沒有人再提起這件事,但我知道,在大家心底或多或少都有留下些許的疙瘩OR不舒服的感覺.所以,隱約中我也有些許地感覺到:那是一種漸行漸遠的心情....
2009年10月19日 星期一
CEO 商業大亨
《商業大亨》「鑽級優先試玩」結果公佈，立即確認您的鑽級尊尚地位！熱爆台港澳三地，《商業大亨》「鑽級優先試玩」申請結果於今天正式公佈，各位有份登記參加抽選「鑽級優先試玩」的準CEO們，於2009年10月16日中午12時後，均可登入「鑽級優先試玩」申請活動頁，查詢申請結果確認自己是否成為《商業大亨》的鑽級CEO！據官方透露，今次集台港澳三地的「鑽級優先試玩」申請，報名人數遠超官方估計，而且更在短時間之內便突破1,000名試玩申請的上限，最後更要緊急加開5,000個試玩名額滿足各準CEO的要求，人氣程......度可想而知，相信即將來臨的優先試玩定必會引發一場《商亨》熱潮！商場如戰場，早著先機才能勝人一籌！官方於優先試玩期間已準備了一連串星級活動，帶領大帶摸索遊戲之餘，達成條件更送您遊戲正式上市時獲得豐富獎品！要如何鞏固自己勢力？如何使策略手段挖天才員工？您都能在優先試玩的活動中一一親身感受！要成為一個成功的CEO靈活運用手上的籌碼是致勝關鍵！領取了「鑽級優先試玩」資格的玩家，記得於10月20日中午12時，準時踏上您的創業之路！
《商業大亨》「鑽級優先試玩」活動頁：http://ceoevent.funmily.com/diamond/index.php
《商業大亨》活動頁：http://ceoevent.funmily.com/cb/
《商業大亨》官方網址：http://ceo.funmily.com
《商業大亨》「鑽級優先試玩」活動頁：http://ceoevent.funmily.com/diamond/index.php
《商業大亨》活動頁：http://ceoevent.funmily.com/cb/
《商業大亨》官方網址：http://ceo.funmily.com
2009年10月16日 星期五
資料庫正規化
資料庫正規化
« 於: 2008-05-13 15:02 »
--------------------------------------------------------------------------------
要寫出一個好的網頁程式並不容易
除了資料的傳遞方式(GET/POST)，頁面的串接，php的語法，SQL語法都得熟悉外
最重要的當然就是資料庫規劃了
不懂的如何規劃，那保證什麼專案都寫不出來
(曾遇過某個天才把所有的欄位統統擺在一個表格內，對每個欄位統統建index來加速)
要如何規劃出一個資料庫呢?
就是這篇的主題了--資料庫正規化
資料庫正規化的目的在於消除重複的資料欄位，確保資料的一致性。
一般來說大概都只會做到第三正規化，所以這邊就只討論到此嘍
正規化只是提供一個資料庫設計的準則，並不是一個強制性的規定，有時為了效能，會做反正規劃的動作
就功能性來區分
第一正規化 消除重複資料群，定義出唯一的索引值
第二正規化 根據表格的功能性，將不相干的欄位分離
第三正規化 根據遞移關係，將欄位分離
第一正規化
引用
第一正規化的幾個規則
一個row就只能陳述一件事
每個row都必須有一個唯一的識別(主鍵)
每個欄位只能陳述一個事情
不能用多個欄位陳述同一見事實
以下是幾個違反的例子
訂單資料
訂單ID 商品ID 購買數量
1 2,3,4 1,3,5
2 1,5,9,10 10,20,1,3
訂單1裡面購買了ID為2的商品，買了1個。
訂單1裡面購買了ID為3的商品，買了3個。
訂單1裡面購買了ID為4的商品，買了5個。
這違反了一個row就只能陳述一件事這條規則
上面的資料應該規劃成以下的方式
訂單ID 商品ID 購買數量
1 2 1
1 3 3
1 4 5
2 1 10
2 5 20
2 9 1
2 10 3
上面的例子 訂單的ID以及商品ID就是這個購買紀錄的唯一識別碼(主鍵)
文章關鍵字的索引
ID 標題 關鍵字
1 資料庫正規化... 資料庫,正規化,php
2 php資料結構... php,資料結構
上面的關鍵字欄位就違反了每個欄位只能陳述一個事情
如果關鍵字的數目不會超過3個
或許就會有人改成這樣的方式
ID 標題 關鍵字1 關鍵字2 關鍵字3
1 資料庫正規化... 資料庫 正規化 php
2 php資料結構... php 資料結構
但這又違反了不能用多個欄位陳述同一見事實這條規則
關鍵字1,2,3，這三個欄位都是用來陳述關鍵字
所以嘍，這就不是個好的方式，況且每次搜尋得跨欄位
比較適合的方式就會像這樣
文章
ID 標題
1 資料庫正規化...
2 php資料結構...
關鍵字索引
關鍵字 文章ID
資料庫 1
正規化 1
php 1
php 2
資料結構 2
未完....待續
« 最後編輯時間: 2008-05-13 17:31 由 Darkhero » 已記錄
--------------------------------------------------------------------------------
我的symfony作品:YOMOpets 寵物誌
有興趣可以一起來討論symfony喔
我的部落格:http://pets.yomopets.com/ricky
micmic3
俺是博士！
文章: 1311
回覆： 資料庫正規化
« 回覆文章 #1 於: 2008-05-13 16:40 »
--------------------------------------------------------------------------------
嗯....好著急啊....怎麼這樣就結束了...
---
這是一篇好文章
已記錄
Darkhero
酷！學園 學長們
俺是博士！
會員性別:
文章: 3337
我家小貓~
回覆： 資料庫正規化
« 回覆文章 #2 於: 2008-05-13 16:54 »
--------------------------------------------------------------------------------
忽然想到....
有好多有上集沒下集的文章..將來是不是要來追一下...
(但是這樣會追到我自己..還是不要好了...)
已記錄
--------------------------------------------------------------------------------
希望我們的討論是為了把問題解決，而不是爭論誰對誰錯.
『灌水才是重點，發文只是順便』
『我寧可讓不會釣魚的工程師餓死，也不想讓會餓死的工程師去攪沉公司....』
哇沙米
可愛的小學生
文章: 28
回覆： 資料庫正規化
« 回覆文章 #3 於: 2008-05-13 17:00 »
--------------------------------------------------------------------------------
資料庫規劃真的也很重要，
好的規劃可以讓往後維護上及可讀性加強，
不遵守正規化真的可以讓設計師偷一點懶…
這篇好文章期待補完
已記錄
jaceju
憂鬱的高中生
文章: 90
回覆： 資料庫正規化
« 回覆文章 #4 於: 2008-05-13 17:20 »
--------------------------------------------------------------------------------
有時候不遵守正規化，其實不僅僅是想偷懶，而是為了效能問題。在資料吞吐量非常大時，就會寧可用空間來換取時間，在每個需要的資料表裡塞入重複的紀錄，避免 JOIN 等耗費時間的運算。
但這樣的處理方式也僅適合資料不常更改的狀況，如果系統需要的是資料的強健性與正確性，那麼正規化還是相當必要的。
個人意見，僅供參考。
已記錄
Darkhero
酷！學園 學長們
俺是博士！
會員性別:
文章: 3337
我家小貓~
回覆： 資料庫正規化
« 回覆文章 #5 於: 2008-05-13 17:29 »
--------------------------------------------------------------------------------
Jace 說的很正確...正規化的資料庫表格, 由於常常需要關聯不同資料表的關係, 有時候會讓資料庫有過多的 join 產生, 這部分在大量資料跟大量存取下, 反而會造成效能低落..
資料庫正規化是初學者必須學習的一個課題, 這是無庸置疑的..
而在資料庫程式打滾一陣子後,尤其當資料量增加非常快,而存取量又大的時候,該怎麼適度的作反正規化來達成用空間換取時間的目標, 則是有經驗的程式設計師,資料庫設計師所需要面臨的下一個課題...
這當中牽扯了關於如何保持資料的正確性, 一致性, 不管是用程式處理, 還是用資料庫的 SP 來處理..都是一門學問了!~...
不過呢..我想, 如果再看本文的朋友若是還不清楚正規化是什麼要幹麻的, 就用心的學好正規化, 然後再來想所謂的空間換時間的方法...
已記錄
--------------------------------------------------------------------------------
希望我們的討論是為了把問題解決，而不是爭論誰對誰錯.
『灌水才是重點，發文只是順便』
『我寧可讓不會釣魚的工程師餓死，也不想讓會餓死的工程師去攪沉公司....』
ricky
區域板主
鑽研的研究生
文章: 560
回覆： 資料庫正規化
« 回覆文章 #6 於: 2008-05-13 18:38 »
--------------------------------------------------------------------------------
會寫這篇的原因是最近接手了前人的攤子
資料庫裡面充斥著垃圾欄位
正規化後的table有時必須靠複雜的join陳述才能將需要的資料select出來
同時寫入資料也得分散在許多table，甚至得啟用transaction
到時候再來舉幾個反正規化的例子吧
=============================
原來舉例子才是最困難的東西
已記錄
--------------------------------------------------------------------------------
我的symfony作品:YOMOpets 寵物誌
有興趣可以一起來討論symfony喔
我的部落格:http://pets.yomopets.com/ricky
« 於: 2008-05-13 15:02 »
--------------------------------------------------------------------------------
要寫出一個好的網頁程式並不容易
除了資料的傳遞方式(GET/POST)，頁面的串接，php的語法，SQL語法都得熟悉外
最重要的當然就是資料庫規劃了
不懂的如何規劃，那保證什麼專案都寫不出來
(曾遇過某個天才把所有的欄位統統擺在一個表格內，對每個欄位統統建index來加速)
要如何規劃出一個資料庫呢?
就是這篇的主題了--資料庫正規化
資料庫正規化的目的在於消除重複的資料欄位，確保資料的一致性。
一般來說大概都只會做到第三正規化，所以這邊就只討論到此嘍
正規化只是提供一個資料庫設計的準則，並不是一個強制性的規定，有時為了效能，會做反正規劃的動作
就功能性來區分
第一正規化 消除重複資料群，定義出唯一的索引值
第二正規化 根據表格的功能性，將不相干的欄位分離
第三正規化 根據遞移關係，將欄位分離
第一正規化
引用
第一正規化的幾個規則
一個row就只能陳述一件事
每個row都必須有一個唯一的識別(主鍵)
每個欄位只能陳述一個事情
不能用多個欄位陳述同一見事實
以下是幾個違反的例子
訂單資料
訂單ID 商品ID 購買數量
1 2,3,4 1,3,5
2 1,5,9,10 10,20,1,3
訂單1裡面購買了ID為2的商品，買了1個。
訂單1裡面購買了ID為3的商品，買了3個。
訂單1裡面購買了ID為4的商品，買了5個。
這違反了一個row就只能陳述一件事這條規則
上面的資料應該規劃成以下的方式
訂單ID 商品ID 購買數量
1 2 1
1 3 3
1 4 5
2 1 10
2 5 20
2 9 1
2 10 3
上面的例子 訂單的ID以及商品ID就是這個購買紀錄的唯一識別碼(主鍵)
文章關鍵字的索引
ID 標題 關鍵字
1 資料庫正規化... 資料庫,正規化,php
2 php資料結構... php,資料結構
上面的關鍵字欄位就違反了每個欄位只能陳述一個事情
如果關鍵字的數目不會超過3個
或許就會有人改成這樣的方式
ID 標題 關鍵字1 關鍵字2 關鍵字3
1 資料庫正規化... 資料庫 正規化 php
2 php資料結構... php 資料結構
但這又違反了不能用多個欄位陳述同一見事實這條規則
關鍵字1,2,3，這三個欄位都是用來陳述關鍵字
所以嘍，這就不是個好的方式，況且每次搜尋得跨欄位
比較適合的方式就會像這樣
文章
ID 標題
1 資料庫正規化...
2 php資料結構...
關鍵字索引
關鍵字 文章ID
資料庫 1
正規化 1
php 1
php 2
資料結構 2
未完....待續
« 最後編輯時間: 2008-05-13 17:31 由 Darkhero » 已記錄
--------------------------------------------------------------------------------
我的symfony作品:YOMOpets 寵物誌
有興趣可以一起來討論symfony喔
我的部落格:http://pets.yomopets.com/ricky
micmic3
俺是博士！
文章: 1311
回覆： 資料庫正規化
« 回覆文章 #1 於: 2008-05-13 16:40 »
--------------------------------------------------------------------------------
嗯....好著急啊....怎麼這樣就結束了...
---
這是一篇好文章
已記錄
Darkhero
酷！學園 學長們
俺是博士！
會員性別:
文章: 3337
我家小貓~
回覆： 資料庫正規化
« 回覆文章 #2 於: 2008-05-13 16:54 »
--------------------------------------------------------------------------------
忽然想到....
有好多有上集沒下集的文章..將來是不是要來追一下...
(但是這樣會追到我自己..還是不要好了...)
已記錄
--------------------------------------------------------------------------------
希望我們的討論是為了把問題解決，而不是爭論誰對誰錯.
『灌水才是重點，發文只是順便』
『我寧可讓不會釣魚的工程師餓死，也不想讓會餓死的工程師去攪沉公司....』
哇沙米
可愛的小學生
文章: 28
回覆： 資料庫正規化
« 回覆文章 #3 於: 2008-05-13 17:00 »
--------------------------------------------------------------------------------
資料庫規劃真的也很重要，
好的規劃可以讓往後維護上及可讀性加強，
不遵守正規化真的可以讓設計師偷一點懶…
這篇好文章期待補完
已記錄
jaceju
憂鬱的高中生
文章: 90
回覆： 資料庫正規化
« 回覆文章 #4 於: 2008-05-13 17:20 »
--------------------------------------------------------------------------------
有時候不遵守正規化，其實不僅僅是想偷懶，而是為了效能問題。在資料吞吐量非常大時，就會寧可用空間來換取時間，在每個需要的資料表裡塞入重複的紀錄，避免 JOIN 等耗費時間的運算。
但這樣的處理方式也僅適合資料不常更改的狀況，如果系統需要的是資料的強健性與正確性，那麼正規化還是相當必要的。
個人意見，僅供參考。
已記錄
Darkhero
酷！學園 學長們
俺是博士！
會員性別:
文章: 3337
我家小貓~
回覆： 資料庫正規化
« 回覆文章 #5 於: 2008-05-13 17:29 »
--------------------------------------------------------------------------------
Jace 說的很正確...正規化的資料庫表格, 由於常常需要關聯不同資料表的關係, 有時候會讓資料庫有過多的 join 產生, 這部分在大量資料跟大量存取下, 反而會造成效能低落..
資料庫正規化是初學者必須學習的一個課題, 這是無庸置疑的..
而在資料庫程式打滾一陣子後,尤其當資料量增加非常快,而存取量又大的時候,該怎麼適度的作反正規化來達成用空間換取時間的目標, 則是有經驗的程式設計師,資料庫設計師所需要面臨的下一個課題...
這當中牽扯了關於如何保持資料的正確性, 一致性, 不管是用程式處理, 還是用資料庫的 SP 來處理..都是一門學問了!~...
不過呢..我想, 如果再看本文的朋友若是還不清楚正規化是什麼要幹麻的, 就用心的學好正規化, 然後再來想所謂的空間換時間的方法...
已記錄
--------------------------------------------------------------------------------
希望我們的討論是為了把問題解決，而不是爭論誰對誰錯.
『灌水才是重點，發文只是順便』
『我寧可讓不會釣魚的工程師餓死，也不想讓會餓死的工程師去攪沉公司....』
ricky
區域板主
鑽研的研究生
文章: 560
回覆： 資料庫正規化
« 回覆文章 #6 於: 2008-05-13 18:38 »
--------------------------------------------------------------------------------
會寫這篇的原因是最近接手了前人的攤子
資料庫裡面充斥著垃圾欄位
正規化後的table有時必須靠複雜的join陳述才能將需要的資料select出來
同時寫入資料也得分散在許多table，甚至得啟用transaction
到時候再來舉幾個反正規化的例子吧
=============================
原來舉例子才是最困難的東西
已記錄
--------------------------------------------------------------------------------
我的symfony作品:YOMOpets 寵物誌
有興趣可以一起來討論symfony喔
我的部落格:http://pets.yomopets.com/ricky
訂閱：
文章 (Atom)
