【问题标题】:Google App Engine Datastore - Keys vs. IdentifiersGoogle App Engine 数据存储区 - 密钥与标识符
【发布时间】:2015-02-17 17:39:47
【问题描述】:

我多次遇到的一个决定是如何处理传递实体的键或嵌入 ID。考虑到数据存储键内置的编码器和编组方法,每种方法似乎都同样可行,但我想知道在这种选择上是否有任何最佳实践。一个示例可能是访问用户文件的 URL,其中用户具有默认的自动生成的数字 ID,其形式为:website.com/users/{userIdentifier}/files

我正在尝试确定数据存储键中嵌入的数字是否比实际的键字符串本身更可取。在野外使用数据存储密钥是否安全?我想标准化我们在整个系统中处理这些标识符的方式,并且想知道在这方面是否有任何最佳实践。

【问题讨论】:

    标签: google-app-engine google-cloud-datastore


    【解决方案1】:

    使用完整密钥而不是标识符的唯一原因是在不传递额外数据的情况下获取嵌入在密钥本身中的祖先信息。虽然这在某些情况下可能很方便,但我认为将键用作应用程序中的标准引用方法并没有足够大的优势。

    使用标识符的优势更显着:(a) 它们更小,(b) 它们不会透露任何关于其祖先的信息(这可能是也可能不是问题)。

    较小的尺寸经常发挥作用:您可能希望在 URL 中使用 id,在 memcache 中保存 id 列表(限制为 1MB)等等。

    【讨论】:

      【解决方案2】:

      数据存储键包含(至少)下一条信息:

      • 亲切
      • 对祖先的引用
      • 字符串或整数 ID

      您真的需要/想要传递 URL 或保留您的 DB AppID 和 Kind 吗?

      比较这 2 个 url(从逻辑上讲,如果是密钥,它可能会被编码为 urlsafe()):

      • /list-of-orders?user=123
      • /list-of-orders?user=User/123

      或者这两个字段:

      Table: Orders
      ---------------------
      | UserKey  | UserID |
      ---------------------
      | User/123 | 123    |
      ---------------------
      

      您为什么要保留和传递有关应用和种类的重复信息?通常,您的应用会引用自己的实体,并且种类由列或参数名称知道。

      除非您在少数应用之间构建一些编排/集成,否则仅使用 ID 会更有效。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2011-02-16
        • 2013-12-03
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多