如何将 Twitter ID 存储在 Core Data 对象中

Posted 2023-03-05

【中文标题】如何将 Twitter ID 存储在 Core Data 对象中

【英文标题】：How to store Twitter ID in Core Data objects

【发布时间】：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：

作为 64 位有符号整数（Core Data 没有无符号整数类型） 作为字符串 作为小数

选项（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 时，底层持久存储中不原生支持的任何内容都可能导致问题。

提前致谢。

【参考方案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