之前已经已经写过一篇《从开放平台建设者角度对应用开发者的一点架构建议(1)》，主要是介绍了最基本的openid、平台数据、应用内部数据的存储建议，这一次我们更深入一点。 对之前的文章，我们提到了三种数据：

• openid-id
• id-平台数据
• id-应用数据

相信大部分个人开发者的第一反应是，上面每份数据建一张表，之间建立很多外键关系。这样的确会有很大的好处，很多数据查询操作都可以直接通过sql语句完成，比如:

1. 通过openid查询id
2. 通过id查询openid
3. 通过用户名查询openid/id
4. 通过应用数据查询openid/id

上面的架构都很好的，并且开发成本非常低，但是这一切的前提是你的应用的用户量有多少。 100w是个坎，100w之前没有任何问题，100w之后，这种架构就是垃圾 很多人会说，对于一个小应用，考虑那么大量用户干嘛？你这是过度设计了吧。 有这种思想的人不少，没错，当年facebook过100w用户的时候，已经是一家有很多职员的公司了。那你会不会觉得，当我们的小应用成长为100w用户的时候，我们已经有了足够的资金，足够的职员，可以考虑重构了？ 然而事实是，zynga新推出的游戏《帝国与同盟》在facebook上上线一周，日活跃就达到3000w，更别说注册用户量。而就国内的情况来说，在朋友网上面的任何一款应用，只要不是太差，1~2个月 ...

2011年，各大平台相继开放，相信关注的朋友都应该知道，6月15日，腾讯也召开了开发者大会，在这里笔者不想就开放本身做太多讨论，作为一个技术博客，我们还是专注讨论技术架构吧。 笔者在腾讯主要负责腾讯开放openapi的开发，也确实见到了不少应用由于架构不当，导致开发维护成本非常高的例子，更重要的是接入成本非常高导致落在了别的应用后面，所以，笔者在这里会结合腾讯开放的一些特点，给应用开发者一点建议。 如果有朋友致力于应用的开放，希望能有所帮助。 我们就从最基本的地方开始说起吧。 开放平台都会提供一个openid，一个openid对应平台上面的一个真实帐号，在腾讯当然就代表的是QQ号。通过openid就可以或者某个人的个人信息，他的好友关系链等等信息。 那么，怎么让openid与应用自身的数据关联起来呢？ 这是我所见到的第一种架构:

一.openid直接作为主键

应用直接将平台的openid来做主键，即应用没有自身的id。 这种方式有什么问题呢？假设说你做的是一个有发展前景的应用，你的应用以后可能会接入facebook，人人，等等开放平台，而每个开放平台的openid格式又都不一样，那么你的数据库表设计将会每个平台的都有一部分不一样，而大部分业务逻辑又都一样，严重违反了“DRY”原则，增加了开发和维护的成本。 所以这种方式不好。

二.有自己的id ...