之前已经已经写过一篇《从开放平台建设者角度对应用开发者的一点架构建议(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个月 ...