大晚上竟然没人来回答我,刚又钻了几个钟头的牛角角,想了这样一个方案不知道可不可行。因为我们的网站每天信息量很大。万来条吧我同时保留ID自动编号,及类似GUID的自段。GUID的字符串字段用来做查询。做为主键。索引。
ID字段作为UPDATE,delete时用。不知道可不可行。丢。。好累呀,高手高手快现啊

解决方案 »

  1.   

    优酷这种伪地址显然不会涉及到所谓的encode和decode,必然是生成的随机伪地址(XODM0NTUyNjA),存于库中,与这个伪地址相关联的也并不存在所谓的真实地址,服务端接受到伪地址ID后,直接查表,得到对应的该页面上需要播放的视频ID,评论列表ID,广告等相关信息就直接输出了.tbl_access_control
    addr_id       user_id       commet_idtbl_user_media
    user_id       media_idtbl_media_list
    media_id      media_uritbl_commet_list
    user_id       media_id      commet差不多就这个样子就可以了,你确实把问题复杂化了,你所担心的效率问题,根本都不成问题,通过建立适当的索引和视图,这方面的效率问题不是你作为web开发者所需要担心的。
    PS:GUID不是.net里的,GUID是哪里有的
      

  2.   

    真正的高手都是月黑风高的时候出现的,我等到快5点了,突然发现有高手出现了。我就说吗。不可能搞那种加解密的。没什么意义。应当是随机生成不重复没有规则的字串存在表里,再通过此字串来直接查记录。那这种字串我在表中怎么设计选用哪种类型,一般要不要定他字串的长度?建主键?索引?与用数字型的那种ID自动编号相比应当效率上不会差很多吧。PS:GUID据说是.NET里的,全球唯一的随机码。JSP里好像也有,不过PHP里好像没得。我也不是很清楚。对,net不是很了解
      

  3.   

    73d6c71e-3f82-45e0-9095-dda4c80d8c58http://topic.csdn.net/u/20090410/00/73d6c71e-3f82-45e0-9095-dda4c80d8c58.htmlcsdn的这个就是标准的guid,那他是以这个做完索引标识去调数据的吗?这么长的册在大数量的情况下会不会对速度有大的影响
      

  4.   

    如果想模仿youku的这种地址,可以再数据库中做几个存储过程,调过程来生成,这种很快的,没什么效率要考虑的问题