首页 > 社交应用的mysql表主键该怎么定义?

社交应用的mysql表主键该怎么定义?

目前在设计一个移动社交应用,涉及的内容有:用户注册、发布图文分享、发表评论等等。

我已经定义好相关的表及其主键,比如用户信息表(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

另外我看到的的问题的url是这样的:https://.com/q/10...,知乎的问题url是这样的:https://www.zhihu.com/questio...,其中的某个答案的url是:https://www.zhihu.com/questio...,这种url路径,我相信应该是restful风格,那些数字应该是相应问题或者回答的主键,请问这种数字类的主键是怎么生成的?数据库是用varchar还是int,像sf这么长的估计还不能用int。

请高手指教,谢谢!


mysql主键最好不用字符型,字符型会导致页断裂,不是顺序写,影响性能不同的业务设计不同的主键生成规则
比如说帖子分类表,顶多几十个直接用mysql自增;
又比如说帖子表,在可以预见的将来可能会增加得很快,以后会设计到分表,分库等,这种业务最好程序维护主键生成不要用自增


其实不应该自己去维护一套类似自增字段的逻辑,sf这个应该是在自增id的基础上加了一个前缀,其实没有多大必要,我理解的好的url规范应该是通俗易懂的,这是我们家的url,尽可能使用自增id做主键,能用整型的不要用字符型,字符型会减慢查询速度增大存储空间


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

【热门文章】
【热门文章】