9

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

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

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

4

5 回答 5

12

HSQLDB 有一个内置UUID类型。使用那个

CREATE TABLE t (
  id UUID PRIMARY KEY
);
于 2017-02-01T08:58:02.070 回答
9

你有几个选择：

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

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

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

于 2009-12-15T16:52:22.263 回答
7

  1. 我会推荐char(36)而不是varchar(36). 不确定hsqldb，但在许多DBMS char 中要快一点。

  2. 对于查找，如果 DBMS 很智能，那么您可以使用整数值“更接近”您的 UUID。

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

WHERE intCol = ? and uuid = ?

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

于 2009-12-15T16:51:12.547 回答
2

使用 BINARY(16) 是另一种可能性。存储空间比字符类型少。使用 CREATE TYPE UUID .. 或 CREATE DOMAIN UUID .. 如上所述。

于 2010-01-17T03:42:55.047 回答
0

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

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

HSQLDB 中的 INT、BIGINT 或 UUID/GUID？（被社区删除...）

HSQLDB：域创建和操作

于 2009-12-15T16:43:49.877 回答