Android：在SQLite中使用UUID作为主键

我的应用程序需要与其他应用程序用户同步（在他们自己的设备上）。我还希望支持脱机编辑，当用户连接到internet时，这些编辑与其他协作用户同步

因此，用户A更改（在脱机时）一些数据（换句话说，他将更新数据库条目）或向数据库添加新记录。当用户A连接到internet时，所有更改和新记录都会传递给其他协作用户。因此，用户B将获得更改/更新，并可以将它们插入/更新到用户B本地设备数据库中

但是我需要确保数据库条目的ID在整个系统中是唯一的。因此我需要使用UUID之类的东西

我的问题：在android sqlite数据库表中使用UUID（String/Varchar）作为主键，而不是使用自动递增的整数，这是一个坏主意吗

我想使用字符串（UUID有36个字符）作为主键会有性能问题

我猜索引UUID而不是整数需要更长的时间（比较字符串和比较整数）。我还猜测，当Im使用UUID时，每次插入新的数据库记录/条目时，数据库都需要重新索引主键列，因为它们的主键索引不再是按排序顺序排列的（这将是我使用整数自动递增主键的时候，因为每个将来的记录都是在末尾添加的，因为新的自动递增主键始终是迄今为止最大的数字，所以索引将自动按顺序排序）。我还需要做的是在2-3个表上进行联接。我还想比较联接上的字符串而不是整数会降低数据库查询的速度

然而，我看不到任何其他的可能性来实现这样一个协作同步系统，所以我必须使用UUID，对吗

另一种可能是使用整数自动递增主键和第二列uuid。因此，要在用户本地设备上工作，我将使用此主键（整数）进行连接等，同时使用uuid列与其他用户同步

你们对这种方法有什么看法？或者你们认为需要做很多工作，因为直接使用UUID作为主键不会带来重大的性能问题

还有其他建议吗

在android sqlite数据库表中使用UUID（String/Varchar）作为主键，而不是使用自动递增的整数，这是一个坏主意吗

我能想到的唯一一个特定问题是，您将无法使用

CursorAdapter

及其子类来显示该表上的查询结果。

CursorAdapter

需要在

Cursor

中使用唯一的整数

\u id

列，并且您可能不会拥有其中的一个。您应该您必须创建自己的适配器，可能是扩展处理它的

BaseAdapter

我想使用字符串（UUID有36个字符）作为主键会有性能问题

可能吧，但如果它在设备大小的数据库上变成一个重大问题，我会有点惊讶

然而，我看不到任何其他的可能性来实现这样一个协作同步系统，所以我必须使用UUID，对吗

您的网络协议需要某种UUID。大概，您的数据库中需要该UUID。我不能说该UUID是否需要成为表的主键，因为我不知道您的模式

另一种可能是使用整数自动递增主键和第二列uuid。因此，要在用户本地设备上工作，我将使用此主键（整数）进行连接等，同时使用uuid列与其他用户同步

正确。您将有一个UUID->local integer ID映射表，在您的网络协议中使用UUID，并保持本地数据库主要使用本地integer ID。这是否会显著提高性能（特别是考虑到数据库架构复杂性的增加），我不能说

你们对这种方法有什么看法？或者你们认为需要做很多工作，因为直接使用UUID作为主键不会带来重大的性能问题

---

总之，要么运行一些性能测试，以便获得一些具体的可比数据，要么只在数据库I/O看起来很慢时才担心它。

可以在一些相关的UUID/SQLite问题中找到UUID的一组二进制和文本性能结果：

---

根据结果，在SQLite中，当索引时，二进制和字符串UUID在创建和查询时都是有效的。一个单独的权衡是，人们可读的字符串是否优先于较小的二进制文件大小的数据大小。

您可以将UUID存储为16字节binary@EirNym当前位置很高兴知道这一点，尽管我看不出这与任务有什么关系ion，答案，或者你显然对我的答案投了反对票。你告诉我ASCII表示法是SQLite3中UUID的唯一表示法，并指出其缺点。二进制表示法没有这样的缺点：它足够快，适用于安卓2.3+的设备，这是2013年建议的最低速度。今天，我们的设备速度更快，我们可以使用not使用SQLite3作为数据库引擎，但它仍然很常见。@EirNym：“您告诉我ASCII表示法是SQLite3中UUID的唯一表示法，并告诉我它的缺点”--我在回答中看不到任何符合您描述的内容。例如，术语“ASCII”仅出现在您的评论和此回复评论中。答案集中在

游标适配器

的要求问题上，您的解决方案也没有解决这些问题。这是类似于

的BLOB类型，您必须使用文本表示法进行直接值比较，但它足够快，可以用作主键/外键.是的，你可以用
varchar