Android:使用UUID作为SQLite的主键

Question

我的应用程序需要与其他应用程序用户同步(在他们自己的设备上)。我还想支持离线编辑，当用户连接到互联网时，这些编辑将同步到其他协作用户。

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

但我需要确保数据库条目的I在整个系统中是唯一的。因此，我需要使用像UUID这样的东西。

我的问题是:在android sqlite数据库表中，使用UUID (String / integer )作为主键，而不是一个会自动递增的整数，是不是一个坏主意？

我猜使用字符串( UUID有36个字符)作为主键会有性能问题。

我猜索引uuid而不是整数需要更长的时间(比较字符串和比较整数)。我还猜测，当Im使用UUID时，每次插入新的数据库记录/条目时，数据库都需要重新索引主键列，因为它们的主键索引不再是排序的顺序(这将是我将使用整数自动增量主键的时候，因为每个未来的记录都添加在末尾，因为新的自动增量主键总是到目前为止的最大数字，所以索引将自动按排序顺序)。我还需要做的是连接超过2-3个表。我还猜测比较JOINS而不是integer上的字符串会降低数据库查询的速度。

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

另一种可能性是使用整数自动递增主键，并使用第二列uuid。因此，为了在用户的本地设备上工作，我将使用这个主键(整数)进行连接等操作，同时使用uuid列与其他用户进行同步。

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

还有其他建议吗？

Answer 1

在android sqlite数据库表中使用UUID (字符串/ Varchar)作为主键，而不是一个会自动递增的整数是不是一个坏主意？

我能想到的唯一可以肯定的问题是，您将不能使用CursorAdapter及其子类来显示表上的查询结果。CursorAdapter需要在Cursor中有一个惟一的整数_id列，而您可能不会有这样的列。您必须创建自己的适配器，也许可以扩展BaseAdapter来处理它。

我猜使用字符串( UUID有36个字符)作为主键会有性能问题。

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

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

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

另一种可能是使用整数自动递增主键，并使用第二列uuid。因此，为了在用户的本地设备上工作，我将使用这个主键(整数)进行连接等操作，同时使用uuid列与其他用户进行同步。

对，是这样。您将拥有一个UUID->本地整数ID映射表，在您的网络协议中使用UUID，并使本地数据库主要使用本地整数ID。这是否会显著提高性能(特别是考虑到数据库模式复杂性的增加)，我不能说。

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

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

Answer 2

UUID的二进制和文本形式的一组性能结果可以在某种程度上相关的UUID/SQLite问题中找到：https://stackoverflow.com/a/11337522/3103448

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