你是否建立過下面結構的表
userid
使用者id（主鍵列）
username
張三用唯一的使用者id作為主鍵。而為了業務需要，你的userid可能是由乙個元件根據某種規則生成的，生成後再存入資料庫。看起來並沒有什麼問題，當乙個需求要維護所有的使用者資訊時百分之90的人都會這樣建表。
假如在原來表結構的基礎上，需求變更為：每個使用者在不同的場景下被視為不同的使用者，既使用者現在又多了乙個場景的概念，在場景1中他可能是張三，但是在場景2中他就是李四了。在此需求下，使用者id+場景id才是唯一的，單純的使用者id已經不唯一了。在如此場景下我們可能需要再去建立一張表，用來標誌使用者和場景一對多的關聯關係。變成：
userid
使用者id（主鍵列）
username
使用者名稱id
無業務含義
userid
使用者id
type
場景型別
由上可以看出，最開始設計的userid主鍵會因為業務的改變而讓整個系統複雜度提高。雖然這是業務變動的常態，但是作為程式設計師，我們需要讓自己的系統更加靈活，更好的適應繁雜的業務。那麼如何去設計乙個合理的主鍵呢？
基於上面的情況，我們在一開始設計表的時候就可以使用這種結構：
id無業務含義（自增主鍵列）
userid
使用者id
username
使用者姓名
以乙個與業務無關的自增列作為主鍵。這樣的靈活性要比直接使用使用者id作為主鍵更高，可以隨時根據業務進行變更，即使表中資料的對應關係從一對一變成一對多，多對多，都可以應對。並且自增主鍵可以加快資料插入的效率。
說說壞處
1.由於自增列並沒有實際業務含義，所以我們的查詢還是要走其他的列，這就無法避免的還需要在其他列上建立索引。與之前相比，需要再多建乙個索引，這就造成了磁碟空間的浪費。
2.自增主鍵在高併發下會有效能的瓶頸。
3.容易暴露業務體量
「使用與業務無關的自增主鍵」，這句話我已經忘記了是從**看的了，當時嗤之以鼻覺得乙個冗餘的主鍵並沒有太大的意義，並且在技術層面也是犧牲了查詢效率和磁碟空間換取了插入效率，當時覺得並不划算。但是隨著專案經驗的增加，我的考慮角度慢慢從技術層面轉到了業務層面，逐漸發現採用這種方式可以讓業務有更大的靈活性。但應用過程中還是需要根據實際情況判斷是否需要，在此只是提供一種表設計的思路。
產品和技術，你選對了嗎？
網際網路的發展史，到今天可以簡短的劃分為三個時代 技術驅動時代 產品驅動時代 運營驅動時代。三個時代對應的三股不同的驅動力量。當一項技術剛剛問世的時候，我們是不能期望它是否方便使用的，因為此時關注的焦點是 有還是沒有 而不會 醜還是美 email沒有介面和互動可言，但它代表著兩台電腦的連線和資訊傳遞...
redis分布式鎖，你真的用對了嗎
隨著業務場景越來越複雜，使用的架構也就越來越複雜，分布式 高併發已經是業務要求的常態。說到分布式，不得不提的就是分布式鎖和分布式事物。今天我們就來談談redis實現的分布式鎖的問題！實現要求 1.互斥性，在同一時刻，只能有乙個客戶端持有鎖 2.防止死鎖，如果持有鎖的客戶端崩潰而且沒有主動釋放鎖，怎樣...
你的float用對了嗎
很多人都知道float是浮點型別，它不能表示資料範圍內的所有數值。但是，實際使用或編碼時，你又是否記得這句話呢？下面是stackoverflow中的乙個問題 why does a float variable stop incrementing at 16777216 下面是待執行的 float a...