問題描述

目前在設計一個移動社交應用，涉及的內容有：用戶注冊、發布圖文分享、發表評論等等。

我已經定義好相關的表及其主鍵，比如用戶信息表（USER_INFO-->USER_ID）、圖文分享表（SHARE_INFO-->SHARE_ID）、評論表（COMMENT_INFO-->COMMENT_ID）,那么請教下這些表的主鍵我應該怎么定義呢，是使用mysql的自增主鍵，還是程序自定義一套業務主鍵？

目前我的設計思路：自定義了一個表，存放每個數據表的表名和當前的表的最大值（如表名：TABLE_MAX，字段：TABLE_NAME、MAX_VALUE），新增數據時，為了防止并發，使用存儲過程獲取下一個主鍵，然后數據表入庫，但是這么做的話就使用到了數據庫的存儲過程的特性，感覺不是很好，代碼如下：

CREATE DEFINER=`root`@`localhost` PROCEDURE `generate_table_id`( in tn varchar(40), out cv int )BEGIN UPDATE table_id_generate SET CURRENT_VALUE = CURRENT_VALUE + 1 WHERE TABLE_NAME=tn; SELECT CURRENT_VALUE into cv from table_id_generate WHERE TABLE_NAME=tn;END

另外我看到的segmentfault的問題的url是這樣的：https://segmentfault.com/q/10...，知乎的問題url是這樣的：https://www.zhihu.com/questio...，其中的某個答案的url是：https://www.zhihu.com/questio...，這種url路徑，我相信應該是restful風格，那些數字應該是相應問題或者回答的主鍵，請問這種數字類的主鍵是怎么生成的？數據庫是用varchar還是int，像sf這么長的估計還不能用int。

請高手指教，謝謝！

問題解答

其實不應該自己去維護一套類似自增字段的邏輯,sf這個應該是在自增id的基礎上加了一個前綴,其實沒有多大必要,我理解的好的url規范應該是通俗易懂的,這是我們家的url,盡可能使用自增id做主鍵,能用整型的不要用字符型,字符型會減慢查詢速度增大存儲空間

自增ID以后不好分表不好水平擴展。

mysql主鍵最好不用字符型，字符型會導致頁斷裂，不是順序寫，影響性能不同的業務設計不同的主鍵生成規則比如說帖子分類表，頂多幾十個直接用mysql自增；又比如說帖子表，在可以預見的將來可能會增加得很快，以后會設計到分表，分庫等，這種業務最好程序維護主鍵生成不要用自增