Хранение UUID в базе данных HSQLDB
Я хочу сохранить созданное использование UUID java.util. UUID в базе данных HSQLDB.
Очевидная опция состоит в том, чтобы просто сохранить их как строки (в коде, их будут, вероятно, просто рассматривать как таковые), т.е. varchar (36).
Что другие опции должны я рассматривать для этого, рассматривая проблемы, такие как размер базы данных и запрашивать скорость (ни один из которых огромное беспокойство из-за объема включенных данных, но я хотел бы рассмотреть их, по крайней мере),
4 ответа
У вас есть несколько вариантов:
- Сохраните его как VARCHAR (36), как вы уже предложили. Это займет 36 байтов (288 бит) для каждого UUID, не считая накладных расходов.
- Сохраните каждый UUID в двух столбцах BIGINT, один для наименее значимых битов и один для наиболее значимых битов; используйте UUID # getLeastSignificantBits () и UUID # getMostSignificantBits () , чтобы захватить каждую часть и сохранить ее соответствующим образом. Это займет 128 бит памяти для каждого UUID, не считая накладных расходов.
- Сохраните каждый UUID как OBJECT; это сохраняет его как двоичную сериализованную версию класса UUID. Я понятия не имею, сколько места это занимает; Мне пришлось бы провести тест, чтобы увидеть, что такое сериализованная форма Java UUID по умолчанию.
Положительные и отрицательные стороны каждого подхода зависят от того, как вы ' повторная передача UUID вокруг вашего приложения - если вы передаете их как их строковые эквиваленты, то обратная сторона необходимости удвоения емкости хранилища для подхода VARCHAR (36), вероятно, перевешивается тем, что вам не нужно преобразовывать их каждый раз, когда вы сделать запрос или обновление БД. Если вы передаете их как собственные UUID, то метод BIGINT, вероятно, требует довольно небольших накладных расходов.
О, и приятно, что вы хотите рассмотреть проблемы скорости и места для хранения, но у многих лучше, чем у меня, есть сказал, также хорошо, что вы понимаете, что они могут не иметь критического значения, учитывая объем данных, которые ваше приложение будет хранить и поддерживать. Как всегда, микрооптимизация ради производительности важна только в том случае, если ее невыполнение приводит к неприемлемым затратам или производительности. Иначе, эти две проблемы - пространство для хранения UUID и время, необходимое для их обслуживания и запроса в БД, - достаточно малозначительны, учитывая дешевую стоимость хранения и способность индексов БД сделать вашу жизнь намного проще. . :)
Я бы порекомендовал
char (36)вместоvarchar (36). Не уверен насчет hsqldb, но во многих СУБД char работает немного быстрее.Для поиска, если СУБД умная, вы можете использовать целочисленное значение, чтобы «приблизиться» к вашему UUID.
Например, добавьте в таблицу столбец типа int, а также char (36). Когда вы вставляете в свою таблицу, вставляйте uuid.hashCode () в столбец int. Тогда ваш поиск может быть таким
WHERE intCol =? и uuid =?
Как я уже сказал, если hsqldb умен, как mysql или sql server, он сузит поиск по intCol, а затем сравнит только несколько значений по uuid. Мы используем этот трюк для поиска по миллиону таблиц записей по строкам, и он по сути так же быстр, как поиск целых чисел.
Я думаю, что проще всего было бы создать свой собственный домен, создавая таким образом свой собственный UUID "тип" (не совсем тип, но почти).
Вам также следует подумать над ответом на этот вопрос (особенно если вы планируете использовать его вместо «обычного» первичного ключа)
INT, BIGINT или UUID / GUID в HSQLDB? (удалено сообществом ...)
Использование двоичного (16) - это другая возможность. Меньше места для хранения, чем типы символов. Используйте создание типа UUID .. Или создать домен UUID .. Как предложено выше.