Хранение UUID в базе данных HSQLDB

Я хочу сохранить UUIDs, созданные с помощью java.утиль.Идентификатор UUID в базе данных HSQLDB.

очевидный вариант-просто хранить их как строки (в коде они, вероятно, будут рассматриваться как таковые), т. е. varchar(36).

какие еще варианты я должен рассмотреть для этого, учитывая такие проблемы, как размер базы данных и скорость запроса (ни один из которых не является огромной проблемой из-за объема данных, но я хотел бы рассмотреть их по крайней мере)

6
hsqldb java uuid

5 ответов

У вас есть несколько вариантов:

  • сохраните его как VARCHAR (36), как вы уже предлагали. Это займет 36 байт (288 бит) хранения на UUID, не считая накладных расходов.
  • храните каждый UUID в двух столбцах BIGINT, один для наименее значимых битов и один для наиболее значимых битов; используйте UUID#getLeastSignificantBits () и UUID#getMostSignificantBits () чтобы захватить каждую часть и храните ее надлежащим образом. Для этого потребуется 128 биты хранения на UUID, не считая накладных расходов.
  • хранить каждый UUID как объект; это сохраняет его как двоичную сериализованную версию класса UUID. Я понятия не имею, сколько места это занимает; мне нужно запустить тест, чтобы увидеть, что такое сериализованная форма Java UUID по умолчанию.

плюсы и минусы каждого подхода основаны на том, как вы передаете UUIDs вокруг вашего приложения-если вы передаете их как их строковые эквиваленты, то недостаток требования удвоить емкость хранилища для подхода VARCHAR (36), вероятно, перевешивается тем, что не нужно преобразовывать их каждый раз при выполнении запроса или обновления БД. Если вы передаете их как родные UUID, то метод BIGINT, вероятно,довольно низок.

О, и приятно, что вы хотите рассмотреть проблемы скорости и пространства для хранения, но, как многие лучше, чем я сказал, также хорошо, что вы признаете, что это может быть не критически важно, учитывая объем данных, ваше приложение будет хранить и поддерживать. Как всегда, микро-оптимизация ради производительности важна только в том случае, если это не приводит к неприемлемым затратам или производительности. В противном случае эти две проблемы-пространство для хранения UUID и время, необходимое для их обслуживания и запроса в БД, - достаточно малозначительны, учитывая дешевую стоимость хранения и способность индексов БД сделать вашу жизнь намного проще. :)

6

  1. Я бы порекомендовал char(36) вместо varchar(36). Не уверен в hsqldb, но во многих СУБД char немного быстрее.

  2. для поиска, если СУБД умна, то вы можете использовать целое значение, чтобы "приблизиться" к вашему UUID.

например, добавьте столбец int в таблицу, а также char(36). При вставке в таблицу вставьте uuid.hashCode () в столбец int. Тогда ваши поиски могут быть похожи это

WHERE intCol = ? and uuid = ?

как я уже сказал, Если hsqldb умный, как mysql или sql server, он сузит поиск intCol, а затем только сравните не более нескольких значений uuid. Мы используем этот трюк для поиска по миллионам + таблиц записей по строкам, и это по существу так же быстро, как поиск целого числа.

7

использование двоичного кода(16) - Еще одна возможность. Меньше места для хранения, чем типы символов. Используйте создать тип UUID .. или создайте UUID домена .. как предлагалось выше.

2
2

Я думаю, что проще всего было бы создать свой собственный домен, таким образом, создав свой собственный UUID "type" (не совсем тип, но почти).

вы также должны рассмотреть ответ на этот вопрос (особенно если вы планируете использовать его вместо "нормального" первичный ключ)

INT, BIGINT или UUID / GUID в HSQLDB?

HSQLDB: создание домена и манипуляции

0