blocks|key|3370952|text|随着GAE构建如何在Django中管理数据，在Django文档中有很多关于如何解决类似问题的信息(例如，请参阅here，向下滚动到“您的第一个模型”)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3370953|简而言之，您将数据库模型设计为常规对象模型，并让GAE对所有对象关系映射进行排序。|3370954|entityMap|0|LINK|mutability|MUTABLE|url|http://www.djangobook.com/en/1.0/chapter05/^0|1J|4|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

As GAE builds on how data is managed in Django there is a lot of info on how to address similar questions in the Django documentation (for example see <a href="http://www.djangobook.com/en/1.0/chapter05/" rel="nofollow noreferrer">here</a>, scroll down to 'Your first model').

In short you design you db model as a regular object model and let GAE sort out all of the object-relational mappings.

blocks|key|368098|text|设计bigtable模式是一个开放的过程，基本上需要您考虑：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|368099|368100|你将使用的访问模式以及每种模式的使用频率|unordered-list-item|368101|368102|你将需要什么索引|368103|你将使用的写模式(为了有效地分散负载)|368104|368105|GAE的数据存储会自动解除数据的规格化。也就是说，每个索引包含(大部分)数据的完整副本，因此每个索引显著增加了执行写入所需的时间和使用的存储空间。|368106|如果不是这样，那么设计一个数据存储模式将是一项更多的工作:您必须仔细考虑每种类型的主键，并考虑您的决策对数据局部性的影响。例如，当呈现一篇博客文章时，您可能需要显示相应的评论，因此每个评论的关键字可能会以相关帖子的关键字开头。|368107|对于数据存储，这并不是什么大问题:您使用的查询将类似于"Select+*+FROM+Comment+WHERE+post_id+=N“。(如果您想对注释进行分页，您还应该有一个limit子句和一个可能的后缀“and+comment_id+>last_comment_id”。)一旦您添加了这样的查询，Datastore将为您构建索引，您的读取速度将变得神奇。|368108|要记住的是，每个额外的索引都会产生一些额外的成本:最好使用尽可能少的访问模式，因为这将减少GAE将构建的索引的数量，从而减少数据所需的总存储空间。|368109|仔细阅读这个答案，我发现它有点含糊。也许一个亲身实践的设计问题会有助于缩小范围？:-)|368110|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Z|8|@]|9|@]|A|$]]|$1|F|3|-4|5|E|7|10|8|@]|9|@]|A|$]]|$1|G|3|H|5|E|7|11|8|@]|9|@]|A|$]]|$1|I|3|J|5|E|7|12|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|14|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|15|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|16|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|17|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|18|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|W|$]]

Designing a bigtable schema is an open process, and basically requires you to think about:

<ul>
<li>The access patterns you will be using and how often each will be used</li>
<li>The relationships between your types</li>
<li>What indices you are going to need</li>
<li>The write patterns you will be using (in order to effectively spread load)</li>
</ul>

GAE's datastore automatically denormalizes your data. That is, each index contains a (mostly) complete copy of the data, and thus every index adds significantly to time taken to perform a write, and the storage space used.

If this were not the case, designing a Datastore schema would be a lot more work: You would have to think carefully about the primary key for each type, and consider the effect of your decision on the locality of data. For example, when rendering a blog post you would probably need to display the comments to go along with it, so each comment's key would probably begin with the associated post's key.

With Datastore, this is not such a big deal: The query you use will look something like "Select * FROM Comment WHERE post_id = N." (If you want to page the comments, you would also have a limit clause, and a possible suffix of " AND comment_id > last_comment_id".) Once you add such a query, Datastore will build the index for you, and your reads will be magically fast.

Something to keep in mind is that each additional index creates some additional cost: it is best if you can use as few access patterns as possible, since it will reduce the number of indices GAE will construct, and thus the total storage required by your data.

Reading over this answer, I find it a little vague. Maybe a hands-on design question would help to scope this down? :-)

blocks|key|365055|text|您可以使用www.web2py.com。您只需构建模型和应用程序一次，它就可以在GAE上运行，也可以在SQLite、MySQL、Posgres、Oracle、MSSQL、FireBird上运行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|365056|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You can use www.web2py.com. You build the model and the application once and it works on GAE but also witl SQLite, MySQL, Posgres, Oracle, MSSQL, FireBird

Since the Google App Engine Datastore is based on <a href="http://research.google.com/archive/bigtable.html" rel="noreferrer">Bigtable</a> and we know that's not a relational database, how do you design a database schema/data model for applications that use this type of database system?

How do you design data models for Bigtable/Datastore (GAE)?

数据存储

数据库

Django

SQLite

MySQL

由于Google App Engine数据存储是基于的，而我们知道它不是关系数据库，那么如何为使用这种数据库系统的应用程序设计数据库schema/data模型呢？

问如何为Bigtable/Datastore (GAE)设计数据模型？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何为Bigtable/Datastore (GAE)设计数据模型？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何为Bigtable/Datastore (GAE)设计数据模型？
EN