在HSQLDB数据库中存储UUID

您有几个选择:

• 正如您已经建议的,将其存储为VARCHAR(36)。这将占用每个UUID 36字节(288位)的存储空间,不包括开销。
• 将每个UUID存储在两个BIGINT列中,一个用于最低有效位,另一个用于最高有效位;使用 UUID#getLeastSignificantBits() 和 UUID#getMostSignificantBits() 抓取每个零件并妥善存放。这将为每个UUID占用128位存储空间,不包括任何开销。

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

哦,你想考虑速度和存储空间的问题是很好的,但是正如我所说的那样,如果你的应用程序将存储和维护的数据量是很重要的,那么你可能认识到这些可能并不重要。一如既往,只有在不这样做会导致不可接受的成本或性能时,为了性能而进行的微观优化才是重要的。否则,这两个问题——UUID的存储空间,以及在数据库中维护和查询UUID所需的时间——的重要性相对较低,因为存储成本低廉,而且数据库索引能够使您的生活更加轻松。:)

HSQLDB has a built-in UUID type. Use that

CREATE TABLE t (
  id UUID PRIMARY KEY
);

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最多只比较几个值。我们使用这个技巧按字符串搜索超过百万个记录表,基本上与整数查找一样快。

使用二进制(16)是另一种可能性。存储空间比字符类型少。使用创建类型UUID。。或创建域UUID。。如上所述。

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

INT, BIGINT or UUID/GUID in HSQLDB? (被社区删除…)

HSQLDB: Domain Creation and Manipulation