我们自己的API的最佳数据结构
我处于为Stack Exchange网络编写Emacs主要模式的早期阶段; 如果您定期使用Emacs,最终将使您受益。 为了最大程度地减少对Stack Exchange API的调用次数(每个IP每天最多10000次),并成为一个负责任的公民,我想缓存从网络收到的信息并将其存储在内存中,等待再次被访问。我真的对存储此信息的数据结构感到困惑。 显然,这将是一个列表。但是,与任何数据结构一样,必须由存储什么数据以及如何访问它们来确定选择。我希望能够将所有这些信息存储在单个符号中,例如stack-api/cache。因此,stack-api/cache事不宜迟,这里列出了最近更新提出的一些要点: `(<csite> <csite> <csite>) <csite>会在哪里 (1362501715 . <site>) 至此,我们所要做的就是定义一个简单的关联列表。当然,我们必须更深入。 每个<site>都是API参数列表(唯一),后跟一个列表问题: `("codereview" <cquestion> <cquestion> <cquestion>) <cquestion>您猜对了,每个问题的最新更新时间都是一个问题: `(1362501715 <question>) (1362501720 . <question>) <question>是question结构和答案列表的缺点(同样,以其上次更新时间为准): `(<question-structure> <canswer> <canswer> <canswer> 和` `(1362501715 . <answer-structure>) 这个数据结构是可能最准确地描述为一棵树,但我不知道是否有更好的方法来做到这一点考虑的语言,的Emacs Lisp(这是不是所有的从Lisp的不同,你知道,爱在所有) 。明确的提示可能是不必要的,但它可以帮助我的大脑更好地围绕它。我敢肯定<csite>,例如,它将变成 (<epoch-time> <api-param> <cquestion> <cquestion> ...) 顾虑: 这样将数据存储在潜在的巨大结构中,是否会对系统的性能进行权衡?我想避免存储无关的数据,但是我已经做了我能做的,并且我认为数据集最初并没有那么大(对于正常使用),因为它只是人类可读文本,而且比例合理。(我正计划使用列表顶部的时间来收集旧数据;每个数据源都从其子级继承其最后更新时间,然后沿树向下继承。该剔除应在多大程度上进行:我不是当然。) 像这样存储数据是否会对必须使用的数据进行性能折衷?也就是说,设置和检索操作是否会受到列表大小的影响? 关于更好的结构,您还有其他建议吗?