我喜欢数据存储区的简单性,可扩展性和易用性; 并且在新的ndb库中找到的增强功能非常棒.
据我了解数据存储区最佳实践,当匹配查询的项目数量很大时,不应编写代码来提供匹配查询结果的项目和/或页面计数; 因为唯一的方法是检索所有资源密集的结果.
然而,在包括我们的许多应用程序中,通常希望看到匹配项目的计数并向用户提供导航到那些结果的特定页面的能力.数据存储分页问题由于需要解决fetch(limit,offset = X)的限制而变得更加复杂,如文章Paging Through Large Datasets中所述.为了支持推荐的方法,数据必须包含一个唯一值列,可以按结果显示的方式进行排序.此列将为每个结果页面定义一个起始值; 保存它,我们可以有效地获取相应的页面,允许按要求导航到特定页面或下一页面.因此,如果要显示以多种方式排序的结果,可能需要维护多个此类列.
应该注意的是,从SDK v1.3.1开始,Query Cursors是推荐的数据存储分页方式.它们有一些限制,包括缺乏对IN和!=过滤器运算符的支持.目前我们的一些重要查询使用IN,但我们将尝试使用OR编写它们以用于查询游标.
遵循建议的指南,可以为用户提供(下一个)和(上一个)导航按钮,以及导航过程中的特定页面按钮.例如,如果用户按下(下一步) 3次,应用程序可以显示以下按钮,记住每个按钮的唯一起始记录或光标以保持导航效率:( 上一页)(第1页)(第2页)(页面) -3)(第4页)(下一步).
有些人建议分别跟踪计数,但是当允许用户查询将改变返回结果的丰富字段时,这种方法是不实际的.
我正在寻找有关这些问题的见解以及以下问题:
您在数据存储区应用中提供了哪些查询结果的导航选项来解决这些限制？
如果为用户提供有效的结果计数和整个查询结果集的页面导航是一个优先事项,那么应该放弃使用数据存储区,以支持现在提供的GAE MySql解决方案.
大表架构或数据存储区实现中是否有任何即将发生的更改,这些更改将提供有效计算查询结果的附加功能？
非常感谢您的帮助.