我正在为一个大型国际品牌设计g +应用程序。我需要创建的实体几乎都是图形的形式,因此有很多多对多关系(弧)连接可以在两个方向上遍历的节点。我正在线上阅读所有可读的文档,但我还没有发现任何特定于ndb设计最佳实践和指南的内容。不幸的是我在nda之下,无法透露应用程序的细节,但它几乎可以与科学会议的背景,论文,作者,论文和主题相匹配。appengine ndb上的图形实体的最佳实践
迄今设想的实体名单如下(与上下文转移到匹配提到的主题):
- 组织(如ACM)
- 会议(如ACM多媒体)
- 会议的问题(例如, ACM多媒体13)
- 发布会上轨(例如NoSQL的,机器学习,计算机视觉等)
- 作者(如我)
- 纸(例如“设计图一样分贝NDB”)
,你可以看到,我可以访问并通过任一方向遍历图形(或面,从一个前端点):
- 笔者用合着者
- 笔者会议跟踪
- 会议跟踪对文件
- ...
等等,你填写清单。
我想让它变得平直和坚实,因为它会用很多p.r.并且需要在内容和用户数量方面不断加班加点。我想从头开始对它进行编码,因此设计了我自己的模型,restful api读/写这些数据,避免使用非rel django并将表示层保持为最小模板机制。我需要与公司在哪里工作,但我们可能能够用一个体面的开源许可证(理想情况下,ndb模型的一个宁静的服务)发布部分代码。
如果任何人都可以指引我走向正确的方向,那就太棒了。
谢谢! 托马斯
[编辑:涉及到许多一对多的关系,纠正错字]
哎dragonx,感谢您抽出时间来回答,但我不知道这能解决我的问题。我认为“referenceProperty”是指一种key =“其他实体之一”的keyProperty,对吧?我读过这个可以轻松达到1mb的限制,当获取具有很多连接的实体时,这可能是我的情况。我可能会为简单的相关实体使用重复的属性,但我认为整个数据结构可能需要依赖更“正常”的表示,因此我将弧作为实体存储的诱惑。说得通? – gru
你是对的,KeyProperty。正如我所提到的,如果您使用方法1,您将遇到1MB的限制,但如果使用方法2则不会。我不知道“规范化”表示的含义。通过将弧存储为实体也不太明白你的意思。如果你的意思是你想为图中两个节点之间的每个链接创建一个实体,那绝对是错误的做法。这将是昂贵的,慢取得实体。在App Engine中,如果可能的话,您通常需要进行非规范化处理,以减少您获取的实体数量,从而节省成本并提高性能。 – dragonx
uhm,我明白你的意思,但我将方法2简单地看作方法1的镜像版本(在我的情况下,所有实体A,B,C ...都可以与其他所有实体建立多对多的连接)所以我会再次遇到1mb的限制。有一个官方的googleplus演示应用程序,它使用我提到的存储实体间连接的方法,[你可以在这里看到它。](https:// github。com/googleplus/gplus-photohunt-server-python/blob/master/model.py#L122)他们不能完全错误,他们必须? – gru