有哪些有效的方法可以对数据库操作执行编程性能测试，尤其是在数据库本身不提供专用工具的环境中？
例如，在 Google App Engine 中，整个页面加载被评估为一项操作，其中可能包括特定的数据库操作。SQLite 和其他集成数据库中也可能存在此问题。由于很难完全抽象需要测试的（等价的）选择和插入，是否有任何推荐的数据库工具来对这些类型的查询执行更彻底的诊断？
performance google-app-engine database-design performance-testing
在常规 Google App Engine 使用、polymodel 或普通“Bigtable”模型中，什么产生最佳性能？
多模型有效地在父表中创建了一个名为“类”的列，它提供了继承跟踪。而从父类继承的普通 Bigtable 创建了一个新的独立数据结构，无法查询父类并找到所有子类型类的所有子类。
在BigTable的设计拒绝了许多标准的关系型模式的哲学的，明确非规范化宁愿到细微的小表的大主机。
这是一个问题的较大领域之一是多对多连接的建模。
对这些连接建模的一种方法是违反第一范式，并将所有有趣的数据放在 db.ListProperty() 中。虽然这可以从查询中进行搜索，但我尚未探讨搜索列表与拉取另一个表对性能的影响。
由于连接是不可能的，这是可以通过RelationshipProperties链接表。因此，只要付出足够的努力，就可以创建标准的交集表（具有引用两个父表的联合主键的表）。有没有人研究过各种实现的性能影响？
-编辑-
虽然文档中建议的密钥列表确实是一种方法，但我对该实现和其他实现的性能和异常率感兴趣。创建密钥的相互列表是否有用？重复获得所付出的努力值得付出代价吗？有没有更好的方法来做到这一点？