Есть идеи, как лучше всего хранить твит-идентификатор Твиттера (и другие идентификаторы элементов данных Твиттера в целом) в поле Базовые данные? Это делается для локального кэширования твитов (и других данных Twitter) и будет использоваться в качестве основного уникального идентификатора для связи локальных данных с данными на стороне сервера. То есть любое новое значение идентификатора, возвращаемое API, будет создавать запись локально, тогда как, если в локальном хранилище данных есть существующий идентификатор, остальные данные будут обновляться независимо от того, что API Twitter возвращает. Так что на этом поле будет сделано много выборок.
Это для библиотеки Core Data для Mac OS X / iOS, а используемое постоянное хранилище - SQLite.
Как вы могли знать, в настоящее время Twitter определяет идентификаторы сообщений как 64-разрядные целые числа без знака . Исходя из этого, я могу думать о следующих опциях хранения идентификаторов Twitter локально:
- как 64-разрядное целое число со знаком (в базовых данных нет целочисленного типа без знака)
- в виде строки
- как десятичное число
Вариант (1) имеет две опасности, которые я могу предвидеть:
- Целочисленные переполнения (переполнение знака), в основном при разборе строкового представления идентификатора.
- Что, если Twitter переполнит 64-битную версию и увеличит диапазон значений идентификаторов?
Опция (2) может быть менее эффективной, поскольку это поле часто используется в выборках.
Опция (3) может быть не более эффективной, чем опция (2), поскольку SQLite 3 не имеет собственного типа числа переменной длины .
Идеальным вариантом, вероятно, является сохранение его в виде 128-разрядного целого числа без знака, что делает их такими же уникальными, как UUID, и не таким большим, как строки. Но, к сожалению, в SQLite нет 128-разрядного целого типа без знака, и все, что не поддерживается в исходном постоянном хранилище, может вызвать проблемы при использовании поля в качестве ключа выборки.
Заранее спасибо.