【问题标题】:How to store Twitter ID in Core Data objects如何将 Twitter ID 存储在 Core Data 对象中
【发布时间】:2011-12-07 07:35:04
【问题描述】:

知道在核心数据字段中存储 Twitter 的推文 ID(以及一般的其他 Twitter 数据项 ID)的最佳方式是什么?这是为了在本地缓存推文(和其他 Twitter 数据),并将用作主要的唯一 ID,以将本地数据与服务器端的数据链接起来。也就是说,API 返回的任何新 ID 值都将在本地创建一条记录,而如果本地数据存储中存在现有 ID,则其余数据将从 Twitter API 返回的任何内容更新。所以会在这个字段上完成很多次提取。

这是用于 Mac OS X / iOS 的 Core Data 库,使用的底层持久存储是 SQLite。

您可能已经知道,目前是Twitter defines message IDs as 64-bit unsigned integers。基于此,我可以想到这些选项在本地存储 Twitter ID:

  1. 作为 64 位有符号整数(Core Data 没有无符号整数类型)
  2. 作为字符串
  3. 作为小数

选项(1)有两个我可以预见的危险:

  • 整数溢出(符号溢出),主要是在解析 ID 的字符串表示时。
  • 如果 Twitter 溢出 64 位并扩大其 ID 值范围怎么办?

选项 (2) 可能效率较低,因为该字段在提取中经常使用。

选项 (3) 可能不会比选项 (2) 更有效,因为 SQLite 3 does not have a native variable-length number type

理想的选择可能是将其存储为 128 位无符号整数,这使得它们与 UUID 一样唯一,并且不会像字符串一样大。但不幸的是,SQLite 中没有 128 位无符号整数类型,并且在使用该字段作为 fetch key 时,底层持久存储中不原生支持的任何内容都可能导致问题。

提前致谢。

【问题讨论】:

    标签: ios macos database-design core-data twitter


    【解决方案1】:

    不会从 64 位切换到 128 位(至少不是出于地址空间之类的任何充分理由),即使它已签名,它仍然会为您留下 63 位,涵盖大约 9,000,000,000,000,000,000 条推文。 Twitter 每天收到 2 亿条推文。即使他们每天有 1 万亿条推文,也需要 900 万天才能溢出。所以在这方面使用 64 位肯定是安全的。

    【讨论】:

    • +1。当您需要担心那里的溢出时,您将对代码进行更多更改。我会选择整数数据类型。
    • 我刚刚查看了 Twitter 如何生成他们的 ID(Snowflake 模式),结果发现他们也只使用 63 位,最重要的 41 位都是应该有效的时间戳 69从 2010 年开始的几年。这是使用有符号整数的一个很好的保证。 github.com/twitter/snowflake#readme
    猜你喜欢
    • 2021-11-17
    • 1970-01-01
    • 2012-03-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-10-20
    • 1970-01-01
    • 2013-12-30
    相关资源
    最近更新 更多