在 HSQLDB 数据库中存储 UUID答案

【问题标题】：Storing UUID in HSQLDB database在 HSQLDB 数据库中存储 UUID
【发布时间】：2010-12-26 21:24:51
【问题描述】：

我希望将使用 java.util.UUID 创建的 UUID 存储在 HSQLDB 数据库中。

显而易见的选择是将它们简单地存储为字符串（在代码中它们可能会被这样对待），即 varchar(36)。

考虑到数据库大小和查询速度等问题，我应该考虑哪些其他选项（由于涉及的数据量，这两者都不是一个大问题，但我想至少考虑一下）

【问题讨论】：

标签： java uuid hsqldb

【解决方案1】：

我认为最简单的做法是创建自己的域，从而创建自己的 UUID“类型”（不是真正的类型，但差不多）。

您还应该考虑这个问题的答案（特别是如果您打算使用它而不是“普通”主键）

INT, BIGINT or UUID/GUID in HSQLDB?（已被社区删除...）

HSQLDB: Domain Creation and Manipulation

【讨论】：

两个链接都坏了。

【解决方案2】：

我会推荐char(36) 而不是varchar(36)。不确定 hsqldb，但在许多 DBMS 中，char 更快。
对于查找，如果 DBMS 很智能，那么您可以使用整数值“更接近”您的 UUID。

例如，向表中添加一个 int 列以及 char(36)。插入表时，将 uuid.hashCode() 插入 int 列。那么你的搜索可以是这样的

WHERE intCol = ? and uuid = ?

正如我所说，如果 hsqldb 像 mysql 或 sql server 一样智能，它将通过 intCol 缩小搜索范围，然后最多仅通过 uuid 比较几个值。我们使用这个技巧通过字符串搜索超过百万个记录表，它本质上与整数查找一样快。

【讨论】：

我喜欢这个主意。由于涉及的记录量，不要认为我们在这里需要它，但我一定会记住它以备将来使用！谢谢。
在 uuid 列上添加索引是否与此解决方案基本相同？

【解决方案3】：

你有几个选择：

按照您的建议，将其存储为 VARCHAR(36)。这将占用每个 UUID 36 字节（288 位）的存储空间，不包括开销。
将每个 UUID 存储在两个 BIGINT 列中，一个用于最低有效位，一个用于最高有效位；使用UUID#getLeastSignificantBits() 和UUID#getMostSignificantBits() 抓取每个零件并妥善存放。这将占用每个 UUID 128 位的存储空间，不计算任何开销。
将每个 UUID 存储为一个 OBJECT；这会将其存储为 UUID 类的二进制序列化版本。我不知道这占用了多少空间。我必须运行一个测试来查看 Java UUID 的默认序列化形式是什么。

每种方法的优缺点取决于您在应用程序中传递 UUID 的方式 - 如果您将它们作为字符串等效项传递，那么需要双倍 VARCHAR 的存储容量的缺点(36) 每次执行数据库查询或更新时不必转换它们可能比方法更重要。如果您将它们作为本机 UUID 传递，那么 BIGINT 方法的开销可能非常低。

哦，您正在考虑考虑速度和存储空间问题，这很好，但正如我所说的那样，考虑到您的应用程序的数据量，这些可能并不是至关重要的，这也很好将存储和维护。与往常一样，为了性能而进行的微优化只有在不这样做会导致不可接受的成本或性能时才重要。否则，这两个问题——UUID 的存储空间，以及在数据库中维护和查询它们所花费的时间——是相当不重要的，因为存储成本低廉，而且数据库索引能够让你的生活变得更美好容易得多。 :)

【讨论】：

嗯...36 * 8 = 256 在哪个宇宙中？ 36 * 8 = 288 在这个：P
唉，我显然生活在自己的宇宙中。 :/ 我会编辑它。

【解决方案4】：

使用 BINARY(16) 是另一种可能性。存储空间比字符类型少。按照上面的建议使用 CREATE TYPE UUID .. 或 CREATE DOMAIN UUID ..。

【讨论】：

【解决方案5】：

HSQLDB has a built-in UUID type. Use that

CREATE TABLE t (
  id UUID PRIMARY KEY
);

【讨论】：

使用PreparedStament getObject 和setObject。这真的很简单。