HSQLDB Internals: Hibernate et Integer vs ID longs

Question

Je crée des Entités de base de données dans mon application Java et essaye de rationaliser entre l'utilisation d'un Integer ou d'un Long comme type de classe du champ "id". J'utilise Hibernate comme ORM qui, à son tour, mappera ce champ à une colonne dans la base de données HSQLDB. Ma lutte est la suivante: un Long est évidemment plus grand et traitera un plus grand nombre d'entrées - mais, à un niveau très bas, je sais que dans le passé (systèmes 32 bits) les lectures au niveau OS auraient une largeur de 32 bits. IE: une lecture longue prendrait deux passages ... est-ce que c'est correct?

Si j'utilise un Long aujourd'hui, mes requêtes HSQLDB seraient-elles plus lentes que si j'avais utilisé un Integer? IE: est-ce que HSQLDB devrait utiliser plusieurs passes de lecture ... ou utiliser une structure interne plus grande ... ou bien ajouter deux colonnes de taille Integer ... ou autre chose évidemment nonideal? Ou, est-ce en quelque sorte un point discutable avec le traitement de 64 bits d'aujourd'hui - qui devrait gérer un Long en une lecture (Long est 64 bits)?

Answer 1

Utilisez un long. Même avec une base de données en mémoire, l'impact sur les performances ne sera probablement pas significatif par rapport au reste de votre application. Ce sera cependant un tracas incroyable de revenir en arrière et de changer l'application plus tard si vous commencez à manquer d'identifiants.