有效实现与Python NDB的一对多关系 [英] Effective implementation of one-to-many relationship with Python NDB

问题描述

我想听听你对Python NDB一对多关系的有效实现的看法。 （例如Person（one）-to-Tasks（many））

在我的理解中，有三种实现方式。

$

1. 使用'parent'参数
   
2. 使用'repeated'结构化属性
关键属性

我通常会根据以下逻辑选择一种方式，但这对您有意义吗？
如果你有更好的逻辑，请教我。

1. 使用'parent'参数
   
   

   
   
   • 这些实体之间需要交易操作
     
   • 这些实体之间需要双向引用
     
   • 强烈希望'Parent-Child'关系
   
   



2. 使用'repeated'结构化属性
   
   

   
   
   • 不需要单独使用'many'实体（总是与'one'实体一起使用）
     
   • 'many'entity仅由一个实体引用
   
   
   • 重复的数量小于100
   
   



3. 使用'重复'键属性
   
   

   
   
   • 需要单独使用'many'实体
   
   
   • '许多'实体可以被其他实体引用
   
   
   • '重复'的数量大于100
     

No.2增加了实体的大小，但我们可以节省t他数据存储操作。 （尽管我们需要使用投影查询来减少CPU的反序列化时间）。因此，我尽可能多地使用这种方式。

我非常感谢您的意见。 方法

你缺少一个关键的东西：你如何阅读数据？

如果你正在显示给定人员的所有任务请求，2是有道理的：你可以查询这个人并显示他所有的任务。然而，如果你需要查询一个所有任务的列表，时间，查询重复的结构化属性是可怕的。您需要单个实体来完成您的任务。

还有第四个选项，即在Task中使用指向您的Person的KeyProperty。如果您需要一个人的任务列表，您可以发出查询。

如果您需要搜索单个任务，那么您可能想要使用＃4。您也可以将它与＃3一起使用。

此外，重复属性的数量与100无关。它与所有的大小有关你的Person和Task实体，以及多少将适合1MB。这是潜在的危险，因为如果你的Task实体可能很大，那么你的Person实体中的空间可能会超出你的预期。

I would like to hear your opinion about the effective implementation of one-to-many relationship with Python NDB. (e.g. Person(one)-to-Tasks(many))

In my understanding, there are three ways to implement it.

1. Use 'parent' argument
2. Use 'repeated' Structured property
3. Use 'repeated' Key property

I choose a way based on the logic below usually, but does it make sense to you? If you have better logic, please teach me.

1. Use 'parent' argument

   • Transactional operation is required between these entities
   • Bidirectional reference is required between these entities
   • Strongly intend 'Parent-Child' relationship

2. Use 'repeated' Structured property

   • Don't need to use 'many' entity individually (Always, used with 'one' entity)
   • 'many' entity is only referred by 'one' entity
   • Number of 'repeated' is less than 100

3. Use 'repeated' Key property

   • Need to use 'many' entity individually
   • 'many' entity can be referred by other entities
   • Number of 'repeated' is more than 100

No.2 increases the size of entity, but we can save the datastore operations. (We need to use projection query to reduce CPU time for the deserialization though). Therefore, I use this way as much as I can.

I really appreciate your opinion.

解决方案

A key thing you are missing: How are you reading the data?

If you are displaying all the tasks for a given person on a request, 2 makes sense: you can query the person and show all his tasks.

However, if you need to query say a list of all tasks say due at a certain time, querying for repeated structured properties is terrible. You will want individual entities for your Tasks.

There's a fourth option, which is to use a KeyProperty in your Task that points to your Person. When you need a list of Tasks for a person you can issue a query.

If you need to search for individual Tasks, then you probably want to go with #4. You can use it in combination with #3 as well.

Also, the number of repeated properties has nothing to do with 100. It has everything to do with the size of your Person and Task entities, and how much will fit into 1MB. This is potentially dangerous, because if your Task entity can potentially be large, you might run out of space in your Person entity faster than you expect.

这篇关于有效实现与Python NDB的一对多关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！