我正在设计一个简单的webapp，每天为用户组织每日圣经阅读。 读数平均每天约300-400字。
因此，例如user1今天注册，因此返回day1的读数。 User2在一周后注册了，但对于他们来说仍然是第一天，所以他们再次获得day1的读数等等。
我预计在发布时会有大约100名用户，以后可能会进行扩展。
现在有两种方法我可以考虑这样做：
1）将整本圣经存储在数据存储区（总共大约30,000节）并查询每天（约50节经文）的读数，同时可能将已经查询过的日期作为文件缓存。
2）让本地脚本在文件中存储每天的读数（总共365个文件）并渲染文件并将其返回给用户而不触及数据存储区。
请记住，在那之后的那一年会有不同的读数，所以如果我选择2，我必须上传一组新的文件。
我真的不知道自己想要什么，以及每个选项的效果如何。 有任何想法吗？我错过了别的什么吗？
答案 0 :(得分：1)
这取决于您希望网站的“动态”程度。如果您每页严格返回一节，那么将所有网页预呈现为HTML将非常具有成本效益。
当您收到用户的请求时，您可以在访问该页面时获取该用户实体，计算相应的经文以显示它们，然后将它们重定向到该页面。另外一个好处是，如果这些页面是静态的，它们可以很好地缓存在Google的边缘缓存中，并且在提供页面方面不会有任何成本。
但是，如果您想动态创建页面，这种机制就不那么有用了。
一般来说，由于这些经文不是一个会改变的数据集，因此将它存储为文件并自己索引这些经文会更便宜。
答案 1 :(得分：0)
稍微抽象一下，用户有一系列要处理的项目。我不清楚读者是按照自己的速度处理，还是以读者开始日期所抵消的固定速率处理。无论哪种方式，都可以直接处理。
您需要一个代表用户的实体。为此，您需要要求用户登录。然后，您可以将其电子邮件地址用作此实体的密钥。如果用户以自己的速度读取读数（但是，比如说，每天不超过一次），那么您可以记录最近一次访问的日期，以及在该日期显示的项目索引（读数） 。当他们在新的日期访问时，索引会前进，并且他们会获得一个新项目（阅读）。
如果根据用户的开始日期确定读数，则实体需要记录其开始日期，以便您可以通过计算当前日期与其开始日期之间的差异来确定读数（相应地调整1-基于索引）。
两种方式都假设您有按数字索引的读数，可以是键值，也可以是某个索引字段。