目前在做乙個rss收集相關的web系統。
1.資料庫是使用多台mysql。
2.用mysql 的 replication來分離讀寫。
3.根據使用者id來分布資料庫中的資料。
問題：1.mysql沒有像oracle中的sequence。自製sequence的話怕影響效率。
2.採用mysql中的自增長主鍵，在分布資料庫中會有重複主鍵問題。鍵值必須在多個資料庫中惟一。
3.在網上查了幾個程式生成的主鍵的方式，似乎都很長最長的要128位，這對與鍵索引來說會太大。
4.用時間到毫秒在加5位隨機數來生成主鍵，但這也要20位，還是不理想。
查詢了公司之前專案的主鍵生成機制。
發現了原專案中用了oracle的sequence，並用一procedure把數字sequence壓縮成字母大小寫在加數字的形式。就是把原來的10進變成64進製,相應的位數就減少了很多。
最後決定用php來寫乙個壓縮數字日期加隨機數的程式來做，把主鍵限定在10以內．
資料庫設計的一些感想
有關主鍵與外來鍵 一般而言，乙個實體不能既無主鍵又無外來鍵。在e r 圖中 處於葉子部位的實體 可以定義主鍵，也可以不定義主鍵 因為它無子孫 但必須要有外來鍵 因為它有父親 主鍵作用是保持唯一性 外來鍵的作用是資料庫的完整性，說白了 就是乙個表某一列的內容 來自於另乙個表的 一列，不能隨便刪除外來鍵...
mysql的主鍵策略 談資料庫主鍵選取策略
int和guid，究竟選誰？如小標題，如果真要選，我會選誰？肯定地說，我會選guid，又或者兩者都選上。後者情形下，使用guid做主鍵 int做小二，int在業務層生成，這要即使重複了，也不礙事，且int是要反饋給前端的，定時做乙個防衝突檢測。如果讓使用者記憶或反饋那guid字串 去連線字元後32位...
資料庫主鍵生成策略
在建立資料庫的時候，需要為每張表指定乙個主鍵，所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組，乙個表只能有乙個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執行資料更新 刪除的時候不會出現張冠李戴的錯誤。資料庫的主鍵生成有多種方式，每種方式都有其優點和缺點，應該根據不同的...