在HSQLDB数据库中存储UUID

时间:2009-12-15 16:35:33

标签: java uuid hsqldb

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

显而易见的选择是将它们简单地存储为字符串(在代码中它们可能只是这样处理),即varchar(36)。

考虑到数据库大小和查询速度等问题,我应该考虑哪些其他选项(由于涉及的数据量很大,这两个问题都不是很重要,但我想至少考虑它们)

5 个答案:

答案 0 :(得分:8)

您有几个选择:

  • 将其存储为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索引使您的生活成为可能而具有相当低的重要性更容易。 :)

答案 1 :(得分:7)

  1. 我建议使用char(36)代替varchar(36)。不确定hsqldb,但在许多DBMS char中要快一点。

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

  3. 例如,在表中添加一个int列以及char(36)。插入表时,将uuid.hashCode()插入int列。然后你的搜索就像这样

    WHERE intCol = ? and uuid = ?

    正如我所说,如果hsqldb像mysql或sql server一样聪明,它将通过intCol缩小搜索范围,然后只用uuid比较最多几个值。我们使用这个技巧按字符串搜索百万+记录表,它基本上和整数查找一样快。

答案 2 :(得分:5)

HSQLDB has a built-in UUID type. Use that

CREATE TABLE t (
  id UUID PRIMARY KEY
);

答案 3 :(得分:2)

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

答案 4 :(得分:0)

我认为最简单的方法是创建自己的域,从而创建自己的UUID“类型”(不是真正的类型,但差不多)。

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

INT, BIGINT or UUID/GUID in HSQLDB?

HSQLDB: Domain Creation and Manipulation