Внутреннее устройство HSQLDB:Спящий режим и целое число против длинных идентификаторов

Question

Я создаю объекты базы данных в своем Java-приложении и пытаюсь рационализировать использование целого числа или длинного типа в качестве типа класса поля «id».Я использую Hibernate в качестве ORM, который, в свою очередь, сопоставляет это поле со столбцом в базе данных HSQLDB.

Моя борьба заключается в следующем:Очевидно, что Long больше и будет обрабатывать большее количество записей, но на очень низком уровне я знаю, что в прошлом (32-битные системы) чтение на уровне ОС было 32-битным.ИЕ:Длинное чтение заняло бы два прохода...это правильное мышление?

Если я сегодня использую Long, будут ли мои запросы HSQLDB выполняться медленнее, чем если бы я использовал Integer?

ИЕ:придется ли HSQLDB каким-то образом использовать несколько проходов чтения...или использовать более крупную внутреннюю структуру...или добавить два столбца целочисленного размера...или что-то еще заведомо неидеальное?Или это какой-то спорный вопрос с сегодняшней 64-битной обработкой - которая должна обрабатывать Long за одно чтение (Long - это 64 бита)?

Answer 1

Используйте длинный.Даже при использовании базы данных в памяти влияние на производительность, скорее всего, не будет значительным по сравнению с остальной частью вашего приложения.Однако будет невероятно сложно вернуться и изменить приложение позже, если у вас начнут заканчиваться идентификаторы.