我正在开发一个应用程序,允许用户通过facebooktwitter注册,我想能够使用他们的个人数据从这些网站,并想知道我应该如何存储它。以下是我迄今为止的研究成果:
user表将存储应该存在的信息,而不管用户如何注册,例如first_name
user_property表将用作key-value缓存并存储特定于facebooktwitter的信息(由origin字段表示)。我将存储可单独用作API调用或SQL查询一部分的属性,如用户的facebook id,并存储以API格式序列化的其他JSON调用的结果,如用户的facebook friends
这样:
我在user表中有一些常用信息,只要一个SELECT表,我就可以获得关于用户的一些基本有用信息
我还有一些来自单独存储的facebook/twitter(例如用户id)的附加属性,我仍然可以使用JOINuser之间的user_property查找。
我可以检索那些昂贵得无法正常存储的信息(例如,创建一个表来存储人们的朋友,并且每个朋友有一个表条目),但在JOINuser之间仍有一个user_property
我现在想知道的是:
问题1:这是一个可持续的数据库设计,还是我弄错了,会遇到一些问题,如果是的话,是哪些问题?
问题2:当存储经常更改的信息(如好友/关注者列表)时,您如何保持信息最新(您是否首先将信息存储在数据库中?如果是,您使用什么条件/触发器来决定何时再次提取信息?

最佳答案

您的设计具有EAV架构的大多数(错误的)属性(实体属性值)。在那件事上寻找Wikipedia并且在这个网站上四处寻找。
使用EAV最不可持续的设计决策是(IMHO),在开始时,这似乎可以很好地扩展。但一旦你的数据增长,你就会以很快的速度撞上一堵水泥墙。这是因为为了加载一个用户的数据,数据库必须使用随机访问来接触物理表的很大一部分。当数据经常增长和更改时,调整数据库以使一个用户的user_property行在相邻页面中保持在一起是一项繁重的任务。

10-05 21:08
查看更多