銀色
2007-08-24 18:28:28 UTC
※ 引述《kong (Life of Music)》之銘言：
真的看不懂原作者的意思。（反覆看了八次）
不過還是可以稍微提一些自己的經驗。
auto_increace 主要的目是在於提供一組簡短的，可供辨識的 unique pky，
而附加價值的是在於 sequence order 之類的其他應用。
一般而言在 pky 設計上只要能達到 unique 目的，其實有很多種方式可以。
鬆散的以 timestamp 而言，嚴謹一點如 md5 (unique) ，
甚至一般大家的 personal id 也可做到。
但是這些不同 pky 所佔用的儲存空間，
或是在 query 處理時需要消耗的暫存記憶卻是不盡相同的。
現在電腦之發達，讓這種差異性極難被注意，
但如果是在有限（非常有限）的記憶體系統上實做時，
每一個儲存都會被要求得很仔細，絕不能浪費，否則本來預估的 3000 筆資料，
最後卻發現只能存進 2600 筆，就因為多使用了空間在規劃 pky 儲存上。
而原作者所提到，我稍稍能看懂的部份，是在於要賦予 pky 意義這點。
不過我和原作者所站的立場截然不同。
畢竟今天資料庫是設計給程式使用的，並不是給一般使用者，
在[1;33m讓程式了解/讓使用者了解[m這兩方面，若是有所取捨，我必然是選擇
讓程式了解為優先。
一來是封裝，在程式物件化中也有這個概念，讓一般使用者所接收到的
『系統設計訊息』是越少越好，封裝過後的資訊可以有效保障系統的安全性
（雖然用處有限），並降低資料傳遞間的複雜度。
二來是程式本身並不是[1;31m寫給使用者看的[m，是寫給使用者[1;31m使用[m，
而實際上有機會去閱讀的多半都是自己或著團隊中的他人，
這種封裝過後的資訊是一開始便要制定好的規格，而非是經由透明化的過程讓它
得以被閱讀/使用。
就像有些老一輩的 myqsql user ，至今不會想去使用 enum 是同樣的道理，
一些以 tinyint 或 boolean 便可解決的東西，為何要透過 enum 來實做？
（當然 enum 有它存在的重要性與特點，這是不容置否的）
好像有點偏離了 XD
回到原作者的文章，要透過一次判斷或兩次判斷來取得權限，
或是進行能否處理資料的判斷，那[1;33;41m 完全是資料庫設計的問題 [m。
與使不使用 auto_increace 全然無關。
你賦予一個 member_table 中 id = xxxx 的資料是表示 xxxx 此人，
那麼你當然也可以賦予他 id = 1 來表示是此人的意義。
而在 member attribute 中，您當然也可以選擇要以 id = xxxx 或 id = 1
來做為對此人的 unique (pky) 判斷。
使用 auto_increace 對我而言絕非是壞習慣，
當然並不是每個 table 都需要使用 auto_increace，
如果一個 table 本身並不需要 pky ，
或著 pky 已經可以被他本身所具有的 unique data 所取代，
那麼當然是否需要 auto_increace 也就不言而喻了。
資料庫的設計，往往決定了一切。
--
[1;30;40m夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子[m
[1;30m之器不得已[37m[30m而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
[m[1;30m矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以[m
[1;30m喪禮處之道常[37m無名[30m樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫[m
[1;30m之令而自均始制有名名亦既有夫亦將知止知止可以不殆譬道之在天下[37m61.229.46.74[30m海[m
以上是一點小例子，至於哪個方法好，我想見仁見智
主要仍是看對設計者而言，怎樣比較方便
至於速度問題，我就不那麼重視了
畢竟真要要求的話，我們應該自己設計硬體，並且從組合語言開始自己寫DBS
但顯然我們沒有餘力這樣做。
[恕刪]主要仍是看對設計者而言，怎樣比較方便
至於速度問題，我就不那麼重視了
畢竟真要要求的話，我們應該自己設計硬體，並且從組合語言開始自己寫DBS
但顯然我們沒有餘力這樣做。
真的看不懂原作者的意思。（反覆看了八次）
不過還是可以稍微提一些自己的經驗。
auto_increace 主要的目是在於提供一組簡短的，可供辨識的 unique pky，
而附加價值的是在於 sequence order 之類的其他應用。
一般而言在 pky 設計上只要能達到 unique 目的，其實有很多種方式可以。
鬆散的以 timestamp 而言，嚴謹一點如 md5 (unique) ，
甚至一般大家的 personal id 也可做到。
但是這些不同 pky 所佔用的儲存空間，
或是在 query 處理時需要消耗的暫存記憶卻是不盡相同的。
現在電腦之發達，讓這種差異性極難被注意，
但如果是在有限（非常有限）的記憶體系統上實做時，
每一個儲存都會被要求得很仔細，絕不能浪費，否則本來預估的 3000 筆資料，
最後卻發現只能存進 2600 筆，就因為多使用了空間在規劃 pky 儲存上。
而原作者所提到，我稍稍能看懂的部份，是在於要賦予 pky 意義這點。
不過我和原作者所站的立場截然不同。
畢竟今天資料庫是設計給程式使用的，並不是給一般使用者，
在[1;33m讓程式了解/讓使用者了解[m這兩方面，若是有所取捨，我必然是選擇
讓程式了解為優先。
一來是封裝，在程式物件化中也有這個概念，讓一般使用者所接收到的
『系統設計訊息』是越少越好，封裝過後的資訊可以有效保障系統的安全性
（雖然用處有限），並降低資料傳遞間的複雜度。
二來是程式本身並不是[1;31m寫給使用者看的[m，是寫給使用者[1;31m使用[m，
而實際上有機會去閱讀的多半都是自己或著團隊中的他人，
這種封裝過後的資訊是一開始便要制定好的規格，而非是經由透明化的過程讓它
得以被閱讀/使用。
就像有些老一輩的 myqsql user ，至今不會想去使用 enum 是同樣的道理，
一些以 tinyint 或 boolean 便可解決的東西，為何要透過 enum 來實做？
（當然 enum 有它存在的重要性與特點，這是不容置否的）
好像有點偏離了 XD
回到原作者的文章，要透過一次判斷或兩次判斷來取得權限，
或是進行能否處理資料的判斷，那[1;33;41m 完全是資料庫設計的問題 [m。
與使不使用 auto_increace 全然無關。
你賦予一個 member_table 中 id = xxxx 的資料是表示 xxxx 此人，
那麼你當然也可以賦予他 id = 1 來表示是此人的意義。
而在 member attribute 中，您當然也可以選擇要以 id = xxxx 或 id = 1
來做為對此人的 unique (pky) 判斷。
使用 auto_increace 對我而言絕非是壞習慣，
當然並不是每個 table 都需要使用 auto_increace，
如果一個 table 本身並不需要 pky ，
或著 pky 已經可以被他本身所具有的 unique data 所取代，
那麼當然是否需要 auto_increace 也就不言而喻了。
資料庫的設計，往往決定了一切。
--
[1;30;40m夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子[m
[1;30m之器不得已[37m[30m而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下
[m[1;30m矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以[m
[1;30m喪禮處之道常[37m無名[30m樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫[m
[1;30m之令而自均始制有名名亦既有夫亦將知止知止可以不殆譬道之在天下[37m61.229.46.74[30m海[m